Jeffrey A Law | 1 Jun 2004 01:06
Picon
Favicon

Re: [PATCH] Fix PR optimization/13653

On Thu, 2004-05-27 at 02:33, Eric Botcazou wrote:
> > It seems to me that if the object is being set inside a loop, then
> > it should never have had the unchanging bit set in the first place.
> > Can you track down how that is happening?
> 
> It's maybe_set_unchanging:
> 
>   /* We can set RTX_UNCHANGING_P from TREE_READONLY for decls whose
>      initialization is only executed once, or whose initializer always
>      has the same value.  Currently we simplify this to PARM_DECLs in the
>      first case, and decls with TREE_CONSTANT initializers in the second.
> */
> 
>   if ((TREE_READONLY (t) && DECL_P (t)
>        && (TREE_STATIC (t) || ! AGGREGATE_TYPE_P (TREE_TYPE (t)))
>        && (TREE_CODE (t) == PARM_DECL
> 	   || DECL_INITIAL (t) == NULL_TREE
> 	   || TREE_CONSTANT (DECL_INITIAL (t))))
>       || TREE_CODE_CLASS (TREE_CODE (t)) == 'c')
>     RTX_UNCHANGING_P (ref) = 1;
> 
> DECL_INITIAL is 0 here so the /u flag is set.
It might help me to see the RTL for the loop in question as well.
Presumably the object we care about has TREE_READONLY set?  But
it's value varies from one iteration to the next (seems to me that
if the value does not vary, then it could not have been a GIV).

> Note this note in loop_invariant_p:
> 
>     case REG:
(Continue reading)

Jeffrey A Law | 1 Jun 2004 01:08
Picon
Favicon

Re: [PATCH] Fix PR optimization/13653

On Fri, 2004-05-28 at 04:51, Gabriel Dos Reis wrote:
> Jeff and all y'all Richards --
> 
>    What is your final judgment?
Unsure at this point.  I'm still trying to figure out how we've
got something with TREE_READONLY set which looks like a GIV.
jeff  

Zack Weinberg | 1 Jun 2004 01:16

Re: PATCH mingw32 Another change to allow mainline to bootstrap.

"Aaron W. LaFramboise" <aaronblue6 <at> cox-internet.com> writes:

>>Like I said, if you have to do this (which it seems you do) then write
>>a proper autoconf check for it.
>
> OK, how about this?

That's correct, and approved.  Don't send diffs for generated files,
please.

> It doesn't look like config.in had been
> regenerated in a while, so some of the changes appear to be unrelated
> to the change to configure.ac.  Thank you for your help, by the way.

There's random churn in config.in from slightly different versions of
autoconf.

zw

Andrew Pinski | 1 Jun 2004 01:29
Picon

[3.4] Fix Ada bootstrap on darwin

I would like to apply the following patch to the 3.4 branch so that it 
will
fix Ada bootstrap on Darwin.  This is the only 3.4.1 bug assigned to me.

OK? Tested on 3.4 branch on powerpc-apple-darwin with new regressions.

Thanks,
Andrew Pinski

ChangeLog:
2003-07-02  Andrew Pinski  <pinskia <at> physics.uc.edu>

	PR target/10129
	* config/darwin.c (darwin_encode_section_info): When the decl has
	a DECL_INITIAL, it is only defined also when it is not a common.

Patch:
Index: darwin.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/darwin.c,v
retrieving revision 1.38
diff -u -p -r1.38 darwin.c
--- darwin.c	7 Jun 2003 17:11:38 -0000	1.38
+++ darwin.c	2 Jul 2003 06:17:51 -0000
 <at>  <at>  -997,7 +997,7  <at>  <at>  darwin_encode_section_info (decl, rtl, f
        && !DECL_EXTERNAL (decl)
        && ((TREE_STATIC (decl)
  	   && (!DECL_COMMON (decl) || !TREE_PUBLIC (decl)))
-	  || (DECL_INITIAL (decl)
+	  || (!DECL_COMMON (decl) && DECL_INITIAL (decl)
(Continue reading)

Steven Bosscher | 1 Jun 2004 01:44
Picon

[PATCH] for "Re: Compilation at -O3 Still Broken"

Hi,

This fixes libjava's PR4766.java test case.

We were removing labels that were still referenced
from exception region structs.  rth, are there other
places you can think if that I've missed?

Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK for mainline?

Gr.
Steven

Steve Kargl | 1 Jun 2004 03:13
Picon

Re: [gfortran] Implement irand(), rand(), and srand() for G77 compatibility

On Mon, May 31, 2004 at 02:55:31PM -0700, Richard Henderson wrote:
> On Sun, May 30, 2004 at 06:21:28PM -0700, Steve Kargl wrote:
>>> You're forgetting that real*4 has significantly less than 32 bits
>>> precision,  so is unable to accurately represent integers of this
>>> magnitude. After rounding the result will in the range [0-1]
>> 
>> Thanks for the wack with the clue stick.
>> 
>> The simple fix is
>> 
>> return (GFC_REAL_4) ((double)(prefix(irand)(i)-1) / (double)GFC_RAND_M1);
> 
> Except if you *really* don't want 1.0 as a result, this won't work either,
> because the double->float conversion will round.  I'm pretty sure what you
> want is truncated rounding, but I'm uncertain how to give you that 
> portably.

Yes, I want the range [0,1), ie., inclusive of 0 and exclusive of 1.

> Probably the easiest portable fix is 
> 
> 	GFC_REAL_4 r = (prefix(irand)(i) - 1) / (GFC_REAL_4)GFC_RAND_M1;
> 	if (r == 1)
> 	  r = nextafterf (1, 0);
> 	return r;
> 
> mod whatever markup you use to select nextafter{,f,l} based on the 
> underlying type of GFC_REAL_4.

The random_number intrinsic uses something similar to
(Continue reading)

James A. Morrison | 1 Jun 2004 03:29
Picon
Picon
Favicon

Re: [PATCH] for "Re: Compilation at -O3 Still Broken"


Steven Bosscher <stevenb <at> suse.de> writes:

> Hi,
> 
> This fixes libjava's PR4766.java test case.
> 
> We were removing labels that were still referenced
> from exception region structs.  rth, are there other
> places you can think if that I've missed?
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
> OK for mainline?
> 
> Gr.
> Steven
> 
> 
> 	* except.c (for_each_eh_region): New function.
> 	* except.h (for_each_eh_region): Add a prototype for it.
> 	* tree-cfg.c (update_eh_labels): New function, callback for
> 	for_each_eh_region.
> 	(label_for_bb): Make global static, unfortunately.
> 	(cleanup_dead_labels): Also update label references for
> 	exception regions.
> 
> Index: except.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/except.c,v
> retrieving revision 1.271
(Continue reading)

Roger Sayle | 1 Jun 2004 04:04
Favicon

Re: Unreviewed patches


On Mon, 31 May 2004, Eric Botcazou wrote:
> Clarify description of -static-libgcc:
> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01712.html

This is OK.

> Fix ACATS failure on i586:
> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01779.html

This is OK for mainline.

> Fix ACATS failures on SPARC:
> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00286.html

This is OK for mainline.

Are these ACATS failures 3.4.x regressions?  If so, you might
want to ask Mark about backporting these patches for gcc 3.4.1
after they've been on mainline for a few days without problems.

Roger
--

Steve Kargl | 1 Jun 2004 04:15
Picon

[gfortran] g77 compatibility patch

The patches and files included here implement the
following g77 functions and subroutines:
  intrinsic functions:   dtime, etime, irand, rand, second.
  intrinsic subroutines: dtime, etime, second, srand.
I have tried to address the rounding issues in rand() that
were discussed in other emails.  I'm sure there are problems
or changes that someone will want to these routines.  Feel
free to fix them.  I will not have time to work on gfortran
for the next 2 to 4 weeks.  The documentation of each function
or subroutine is contained in g77.info.

ChangeLog for gcc/fortran

2004-05-31  Steven G. Kargl  <kargls <at> comcast.net>
     * check.c (gfc_check_second_sub, gfc_check_irand, gfc_check_rand
       gfc_check_srand, gfc_check_etime, gfc_check_etime_sub): New functions.
     * gfortran.h (gfc_generic_isym_id): New symbols GFC_ISYM_ETIME,
       GFC_ISYM_IRAND, GFC_ISYM_RAND, GFC_ISYM_SECOND.
     * trans-intrinsic.c:  Use symbols.
     * intrinsic.c (add_sym_2s): New function.
     * intrinsic.c: Add etime, dtime, irand, rand, second, srand.
     * intrinsic.h: Function prototypes.
     * iresolve.c (gfc_resolve_etime_sub, gfc_resolve_second_sub 
       gfc_resolve_srand):  New functions.

ChangeLog for libgfortran

2004-05-31  Steven G. Kargl  <kargls <at> comcast.net>
     * Makefile.am: Add rand.c and etime.c
     * Makefile.in: Regenerated.
(Continue reading)

Giovanni Bajo | 1 Jun 2004 04:32
Picon
Favicon

[C++ PATCH] [PR14932] Allow subscript operator in offsetof

Hello Mark,

this is the straightforward fix for a small regression in the parser, where we
forgot to allow subscript operators within offsetof.

Testied on i686-pc-linux-gnu, OK for mainline and 3.4?

Giovanni Bajo

cp/
        PR c++/14932
        * parser.c (cp_parser_postfix_expression): Allow subscript
        operator in offsetof.

testsuite/
        PR c++/14932
        * g++.dg/parse/offsetof4.C: New test.

Index: parser.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/parser.c,v
retrieving revision 1.192
diff -c -3 -p -r1.192 parser.c
*** parser.c 13 May 2004 06:40:19 -0000 1.192
--- parser.c 1 Jun 2004 00:39:01 -0000
*************** cp_parser_postfix_expression (cp_parser
*** 3781,3789 ****
         = grok_array_decl (postfix_expression, index);
       idk = CP_ID_KIND_NONE;
       /* Array references are not permitted in
(Continue reading)


Gmane