Re: GCC Plugins (again)

[Emmanuel Fleury]

[EMAIL PROTECTED] wrote:
>> Plugins features.  This addresses Richard Stallman's concerns, so he
>> no
>> longer objects to a Plugins feature.
> 
> That is GREAT news!!!

I add my enthusiasm to the one of Brendon, this is really a great news !
Please, keep us informed of the progress of the plugins !

Regards
-- 
Emmanuel Fleury

Release early. Release often. And listen to your customers.
  -- Eric S. Raymond (The Cathedral and the Bazaar)

Re: PR37363: PR36090 and PR36182 all over again (was: Re: Call for testers, ppc64-linux)

[Paolo Bonzini]

> I got negative feedback on that patch (no, not regression
> results :) on IRC from David Edelsohn and understandably you
> held off your testing because of this, as for one the patch
> affects the rs6000 backend.

What kind of negative feedback?

> For CRIS (as well as other targets IIUC) the cause of PR37363 is
> that there's code that wraps a MINUS of two symbol_ref's in a
> CONST without checking that the two symbol_ref's make up a valid
> address.  After that, the CONST effectively acts as a barrier
> for target hooks ("no need to look, we know that thing there is
> a valid constant expression").

The three possibilities I see are:

1) removing the wrapping CONST?

2) using the patch in
http://gcc.gnu.org/bugzilla/attachment.cgi?id=15620&action=view which
however just papers around this problem.

3) adding a check that the MINUS is a legitimate address, and only wrap
it in CONST if it is.

Paolo

Re: PR37363: PR36090 and PR36182 all over again (was: Re: Call for testers, ppc64-linux)

[Hans-Peter Nilsson]

> Date: Fri, 05 Sep 2008 12:55:17 +0200
> From: Paolo Bonzini <[EMAIL PROTECTED]>

> > I got negative feedback on that patch (no, not regression
> > results :) on IRC from David Edelsohn and understandably you
> > held off your testing because of this, as for one the patch
> > affects the rs6000 backend.
> 
> What kind of negative feedback?

Oh, just that it was papering over the bug. :)  To be honest, I
hadn't checked myself that the patch was not doing something
like that and it wasn't obvious enough to me.  Still, now being
at stage3, IMHO that's as valid solution a solution as it was
for 4.3.

> The three possibilities I see are:
> 
> 1) removing the wrapping CONST?

Nope, not if it's a (MINUS (symbol_ref sym2) (symbol_ref sym1)).
*If* valid, that's a constant expression and *should* be wrapped
in a CONST.  (No, it's not valid for *any* ELF-target in a
single symbolic expression, at least never when sym1 and sym2
aren't in the same section and sym1 not in the same section as
the code.  ISTR there was some IEEE object format in which it'd
be valid as an expression.)

> 2) using the patch in
> http://gcc.gnu.org/bugzilla/attachment.cgi?id=15620&action=view which
> however just papers around this problem.

Right, that's what's been tested but which got negative
feedback.

> 3) adding a check that the MINUS is a legitimate address, and only wrap
> it in CONST if it is.

s/address/constant/; it's not clear that it's used as an address
at that point; it's just two expressions that gcc tries to
reduce.

But I get the point; I'm leaning towards something like
strengthening that it's a legitimate constant.  See
 and
other comments in that PR.  But... should we really redefine
LEGITIMATE_CONSTANT_P and its documentation at this stage?

brgds, H-P

Re: PR37363: PR36090 and PR36182 all over again (was: Re: Call for testers, ppc64-linux)

[David Edelsohn]

On Fri, Sep 5, 2008 at 7:25 AM, Hans-Peter Nilsson
<[EMAIL PROTECTED]> wrote:
>> Date: Fri, 05 Sep 2008 12:55:17 +0200
>> From: Paolo Bonzini <[EMAIL PROTECTED]>

> Nope, not if it's a (MINUS (symbol_ref sym2) (symbol_ref sym1)).
> *If* valid, that's a constant expression and *should* be wrapped
> in a CONST.  (No, it's not valid for *any* ELF-target in a
> single symbolic expression, at least never when sym1 and sym2
> aren't in the same section and sym1 not in the same section as
> the code.  ISTR there was some IEEE object format in which it'd
> be valid as an expression.)

>> 3) adding a check that the MINUS is a legitimate address, and only wrap
>> it in CONST if it is.

simplify_plus_minus was tearing apart and reordering

(CONST (MINUS (SYMBOL_REF1) (SYMBOL_REF2)))

when combined with

(PLUS (REG) (CONST_INT))

binding the CONST_INT more tightly with one of the SYMBOL_REFs


The rs6000 port needs the SYMBOL_REFs bound tightly and
simplify_plus_minus should not insist that a CONST_INT is
better.

CRIS and other ports are experiencing problems because the
new algorithm in simplify_plus_minus is creating the CONST
difference of SYMBOL_REFs in different sections.

Instead of trying to teach simplify_plus_minus the precedence
of these objects, should there be some RTL idiom(s) of

(CONST (MINUS (X) (Y)))

that it leaves untouched?

Thanks, David

Re: PR37363: PR36090 and PR36182 all over again

[Paolo Bonzini]

>> 3) adding a check that the MINUS is a legitimate address, and only wrap
>> it in CONST if it is.
> 
> s/address/constant/; it's not clear that it's used as an address
> at that point; it's just two expressions that gcc tries to
> reduce.

Right.

> But I get the point; I'm leaning towards something like
> strengthening that it's a legitimate constant.  See
>  and
> other comments in that PR.  But... should we really redefine
> LEGITIMATE_CONSTANT_P and its documentation at this stage?

We can do it incrementally.  For now, only redefine
LEGITIMATE_CONSTANT_P on CRIS and in the documentation, and use it in
simplify_plus_minus.  For 4.5, we can look at other places using
gen_rtx_CONST and strengthen them too.

Paolo

Re: PR37363: PR36090 and PR36182 all over again

[Hans-Peter Nilsson]

> Date: Fri, 05 Sep 2008 14:42:11 +0200
> From: Paolo Bonzini <[EMAIL PROTECTED]>

> We can do it incrementally.  For now, only redefine
> LEGITIMATE_CONSTANT_P on CRIS and in the documentation, and use it in
> simplify_plus_minus.  For 4.5, we can look at other places using
> gen_rtx_CONST and strengthen them too.

Ok, but I'd like to make one that is usable for all ELF targets,
but perhaps not change it universally at this time (I mean, not
providing it in elfos.h or similar).

Maybe as part of a change from target macro to target hook, with
LEGITIMATE_CONSTANT_P as a default would fit, even at this
stage?

brgds, H-P

Re: PR37363: PR36090 and PR36182 all over again

[Hans-Peter Nilsson]

> Date: Fri, 5 Sep 2008 14:57:00 +0200
> From: Hans-Peter Nilsson <[EMAIL PROTECTED]>

> Maybe as part of a change from target macro to target hook, with
> LEGITIMATE_CONSTANT_P as a default would fit, even at this
> stage?

Sorry, I mean CONSTANT_P, not LEGITIMATE_CONSTANT_P.  Or maybe a
new macro or hook; LEGITIMATE_CONSTANT_P isn't applicable,
contrary to the comment in cse.c (see the docs and its use; it's
not about being a valid constant at all, it's about being valid
for certain insns).  For the record.

brgds, H-P

IRA performance regressions on PPC

[Luis Machado]

Hi Vladimir,

I was just going through some benchmarks on PPC and noticed that your
patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
caused a significant regression on both facerec (~17%) and applu (~4%)
for 64-bit PPC.

There are other degradations that i'm still working on isolating the
cause, just to give you a heads up on the problem.

Luis

Re: IRA performance regressions on PPC

[H.J. Lu]

On Fri, Sep 5, 2008 at 6:59 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> Hi Vladimir,
>
> I was just going through some benchmarks on PPC and noticed that your
> patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
> caused a significant regression on both facerec (~17%) and applu (~4%)
> for 64-bit PPC.
>
> There are other degradations that i'm still working on isolating the
> cause, just to give you a heads up on the problem.
>

Can you try ira-merge branch? There is one patch:

http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00427.html

which is supposed to improve SPEC CPU performance.
But no one can explain why.

Thanks.

-- 
H.J.

Re: New assert in haifa-sched.c

[Maxim Kuvyrkov]

Adam Nemet wrote:

haifa-sched.c:
  2302/* Let the target filter the search space.  */
  2303for (i = 1; i < ready->n_ready; i++)
  2304  if (!ready_try[i])
  2305{
  2306  insn = ready_element (ready, i);
  2307  
  2308  gcc_assert (INSN_CODE (insn) >= 0
  2309  || recog_memoized (insn) < 0);

I am hitting this assert with the Octeon pipeline patch.  Isn't the check on
recog_memoized reversed?  Or are we really asserting here that the insn has
either been recognized earlier or won't be recognized now either?!


Yes, the assert is really checking exactly that.  Several pieces of 
haifa-sched.c assume that the instruction has been recognized during 
scheduler initialization to speed up checking if instruction is normal 
or some kind of use/clobber/asm.


As max_issue () is one of hot spots in scheduler (and compiler), not 
calling recog_memoized() saves up some time.


If the assert is failing, then something is wrong at initialization stage.

--
Maxim

Re: IRA performance regressions on PPC

[Luis Machado]

On Fri, 2008-09-05 at 07:16 -0700, H.J. Lu wrote:
> On Fri, Sep 5, 2008 at 6:59 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> > Hi Vladimir,
> >
> > I was just going through some benchmarks on PPC and noticed that your
> > patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
> > caused a significant regression on both facerec (~17%) and applu (~4%)
> > for 64-bit PPC.
> >
> > There are other degradations that i'm still working on isolating the
> > cause, just to give you a heads up on the problem.
> >
> 
> Can you try ira-merge branch? There is one patch:
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00427.html
> 
> which is supposed to improve SPEC CPU performance.
> But no one can explain why.
> 
> Thanks.
> 

Hi,

The patch didn't change the numbers. I still see the same degradation on
both facerec and applu.

Thanks,
Luis

Re: Please, do not use the merged revisions log as the commit message when merging

[Christopher Faylor]

On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
> Daniel Berlin wrote:
>
>> It's listed on the wiki that explains how to maintain branches :)
>>   
> I had no idea such a wiki even existed.  It would really help future 
> contributors, I'm sure, if, perhaps during copyright assignment, there were 
> some sort of "introduction" process that clearly communicated policies.  
> Thank you for the heads up.

But, you did do it again, just a little while ago.

Please stop doing that!  You're swamping gcc.gnu.org and causing unnecessary
work for me.

I will be instituting some safeguards against this kind of mail-bombing going
forward but, nevertheless, this really should not be a common occurrence.

cgf

Re: IRA copy heuristics

[Vladimir Makarov]

David Edelsohn wrote:

On Thu, Sep 4, 2008 at 7:39 PM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
  

Meanwhile I am going to submit your second patch with an added
comment.  The patch permits gcc to generate the same quality code as
before your first patch.



Why?

As Richard said before:

"... it changes
the heuristics _without any explanation of why this is necessary_.
IMO, that's unacceptable for our shiny, new (and generally very nice)
register allocator.  And I think it's unacceptable even if it happens
to fix a performance regression."

The patch does not seem to have any justification other than it fixes the
symptom.


  
 It fixes the performance degradation.  I wrote a long comment for the 
macro about necessity of the problem investigation and marked it by 
???.  The problem is known.  It is actually three monts old (that is 
when Richard submitted the patch first time).  I've tried  to find a 
reason for the degradation which is not easy when you are trying to do 
this on SPEC programs but failed.  Richard found one problem on a small 
test he thought that it could be a reason.  Most part of the problem is 
solved now, so I doubt that was a real reason.


Now I am really busy with fixing IRA bugs.  So if it is ok to gcc 
community to wait for month or two (but may be it will take less who 
knows) to find a real reason or explanation of the performance 
degradation, it is ok for me too.

Re: IRA performance regressions on PPC

[Vladimir Makarov]

Luis Machado wrote:

Hi Vladimir,

I was just going through some benchmarks on PPC and noticed that your
patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
caused a significant regression on both facerec (~17%) and applu (~4%)
for 64-bit PPC.

There are other degradations that i'm still working on isolating the
cause, just to give you a heads up on the problem.
  


Thanks for testing IRA, Luis.  Could you give me more details:

 What machine you are using for this?
 What options (especially march or mtune) you are using?  IRA is very 
sensitive to correct times of ld/st/moves in machine description.

 What is overall IRA regression on SPEC2000?

You could use the same version of the compiler with IRA (default) and 
old RA (-fno-ira).

Bootstrap failure on sparc-sun-solaris2.10

[Art Haas]

Hi.

My build attempts on sparc-sun-solaris2.10 haven't been working well
since the IRA merge, but given the scope of that change and the fixes
applied since the merge I'm certain the build will be in good shape
soon.

This morning's build attempt failed while compiling libgcc:

/export/home/arth/src/gcc.git/libgcc/../gcc/libgcc2.c: In function
'__moddi3':
/export/home/arth/src/gcc.git/libgcc/../gcc/libgcc2.c:1125: internal
compiler error: in choose_ready, at haifa-sched.c:2309

A similar failure in the haifa-sched.c code was sent to the mailing list
earlier today:

http://gcc.gnu.org/ml/gcc/2008-09/msg00106.html

Art Haas

Re: IRA performance regressions on PPC

[Luis Machado]

On Fri, 2008-09-05 at 09:03 -0700, H.J. Lu wrote:
> On Fri, Sep 5, 2008 at 8:01 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> > On Fri, 2008-09-05 at 07:16 -0700, H.J. Lu wrote:
> >> On Fri, Sep 5, 2008 at 6:59 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> >> > Hi Vladimir,
> >> >
> >> > I was just going through some benchmarks on PPC and noticed that your
> >> > patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
> >> > caused a significant regression on both facerec (~17%) and applu (~4%)
> >> > for 64-bit PPC.
> >> >
> >> > There are other degradations that i'm still working on isolating the
> >> > cause, just to give you a heads up on the problem.
> >> >
> >>
> >> Can you try ira-merge branch? There is one patch:
> >>
> >> http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00427.html
> >>
> >> which is supposed to improve SPEC CPU performance.
> >> But no one can explain why.
> >>
> >> Thanks.
> >>
> >
> > Hi,
> >
> > The patch didn't change the numbers. I still see the same degradation on
> > both facerec and applu.
> >
> 
> Did you use mainline or ira-merge branch? Mainline has so many changes
> after IRA merge, any of which can impact SPEC performance. The ira-merge
> branch is mainline at revision 139590 + IRA fixes. It can be used to compare
> IRA performance against revision 139589.

I used the mainline + patch. I'll try the branch in a while, though the
SPEC numbers for these testcases are pretty much the same after IRA has
been merged until today's trunk.

Thanks,
Luis

Re: Please, do not use the merged revisions log as the commit message when merging

[Manuel López-Ibáñez]

2008/9/5 Christopher Faylor <[EMAIL PROTECTED]>:
> On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
>> Daniel Berlin wrote:
>>
>>> It's listed on the wiki that explains how to maintain branches :)
>>>
>> I had no idea such a wiki even existed.  It would really help future
>> contributors, I'm sure, if, perhaps during copyright assignment, there were
>> some sort of "introduction" process that clearly communicated policies.
>> Thank you for the heads up.
>
> But, you did do it again, just a little while ago.
>
> Please stop doing that!  You're swamping gcc.gnu.org and causing unnecessary
> work for me.
>
> I will be instituting some safeguards against this kind of mail-bombing going
> forward but, nevertheless, this really should not be a common occurrence.

Please Christopher, feel free to take my patch at here, modify it,
test it and ping whoever is responsible to review such changes:
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01972.html

Unfortunately, I cannot work on GCC at the moment, so I cannot do it myself.

Cheers,

Manuel.

Re: IRA performance regressions on PPC

[Luis Machado]

On Fri, 2008-09-05 at 12:36 -0400, Vladimir Makarov wrote:
> Luis Machado wrote:
> > Hi Vladimir,
> >
> > I was just going through some benchmarks on PPC and noticed that your
> > patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
> > caused a significant regression on both facerec (~17%) and applu (~4%)
> > for 64-bit PPC.
> >
> > There are other degradations that i'm still working on isolating the
> > cause, just to give you a heads up on the problem.
> >   
> 
> Thanks for testing IRA, Luis.  Could you give me more details:

Yes, of course.
> 
>   What machine you are using for this?

This is a Power6 4.7Ghz (altivec supported)

>   What options (especially march or mtune) you are using?  IRA is very 
> sensitive to correct times of ld/st/moves in machine description.

I'm currently using two tuning setups.

base flags: -m64 -O2 -mcpu=power4
peak flags: -m64 -O3 -mcpu=power4 -ffast-math -ftree-loop-linear -funroll-loops 
-fpeel-loops

>   What is overall IRA regression on SPEC2000?

I don't have that information on this box yet. But i'll have it soon and
will let you know. Right now i only focused on those two degraded
benchmarks.

> You could use the same version of the compiler with IRA (default) and 
> old RA (-fno-ira).

Thanks for the tip. Is it a good idea to go through the ira-merge branch
as well? Or would this suffice?

Thanks,
Luis

Re: IRA performance regressions on PPC

[H.J. Lu]

On Fri, Sep 5, 2008 at 8:01 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-09-05 at 07:16 -0700, H.J. Lu wrote:
>> On Fri, Sep 5, 2008 at 6:59 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
>> > Hi Vladimir,
>> >
>> > I was just going through some benchmarks on PPC and noticed that your
>> > patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
>> > caused a significant regression on both facerec (~17%) and applu (~4%)
>> > for 64-bit PPC.
>> >
>> > There are other degradations that i'm still working on isolating the
>> > cause, just to give you a heads up on the problem.
>> >
>>
>> Can you try ira-merge branch? There is one patch:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00427.html
>>
>> which is supposed to improve SPEC CPU performance.
>> But no one can explain why.
>>
>> Thanks.
>>
>
> Hi,
>
> The patch didn't change the numbers. I still see the same degradation on
> both facerec and applu.
>

Did you use mainline or ira-merge branch? Mainline has so many changes
after IRA merge, any of which can impact SPEC performance. The ira-merge
branch is mainline at revision 139590 + IRA fixes. It can be used to compare
IRA performance against revision 139589.


-- 
H.J.

Re: IRA performance regressions on PPC

[Vladimir Makarov]

Luis Machado wrote:


This is a Power6 4.7Ghz (altivec supported)

  

Great.  Now I have an access to power6.  So I am going to try it too.
  What options (especially march or mtune) you are using?  IRA is very 
sensitive to correct times of ld/st/moves in machine description.



I'm currently using two tuning setups.

base flags: -m64 -O2 -mcpu=power4
peak flags: -m64 -O3 -mcpu=power4 -ffast-math -ftree-loop-linear -funroll-loops 
-fpeel-loops

  

  What is overall IRA regression on SPEC2000?



I don't have that information on this box yet. But i'll have it soon and
will let you know. Right now i only focused on those two degraded
benchmarks.

  
You could use the same version of the compiler with IRA (default) and 
old RA (-fno-ira).



Thanks for the tip. Is it a good idea to go through the ira-merge branch
as well? Or would this suffice?


  


H.J. Lu keeps ira-branch merge more fresh than trunk.  But the lag is 
only 1-3 days usually because gcc community and RA reviewers are very 
responsive.  So I don't see a big difference in using ira-merge and 
trunk.  I'd only recommend to apply patch


http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00427.html

first because it is critical for performance but I don't know when it 
will be approved.

Re: IRA performance regressions on PPC

[H.J. Lu]

On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>
> H.J. Lu keeps ira-branch merge more fresh than trunk.  But the lag is only

I won't apply any non-IRA related patches to ira-merge branch so
that you can get a fair comparison for IRA without regressions
introduced by other changes.

> 1-3 days usually because gcc community and RA reviewers are very responsive.
>  So I don't see a big difference in using ira-merge and trunk.  I'd only
> recommend to apply patch
>
> http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00427.html
>
> first because it is critical for performance but I don't know when it will
> be approved.
>

I checked this patch into ira-merge branch.



-- 
H.J.

Re: Bootstrap failure on sparc-sun-solaris2.10

[Rainer Orth]

Art Haas <[EMAIL PROTECTED]> writes:

> My build attempts on sparc-sun-solaris2.10 haven't been working well
> since the IRA merge, but given the scope of that change and the fixes
> applied since the merge I'm certain the build will be in good shape
> soon.
> 
> This morning's build attempt failed while compiling libgcc:
> 
> /export/home/arth/src/gcc.git/libgcc/../gcc/libgcc2.c: In function
> '__moddi3':
> /export/home/arth/src/gcc.git/libgcc/../gcc/libgcc2.c:1125: internal
> compiler error: in choose_ready, at haifa-sched.c:2309

When I tried mainline bootstrap on sparc-sun-solaris2.11 as of 20080903
(rev 139939), I get a configure failure in stage2 libgcc:

checking for suffix of object files... configure: error: in 
`/vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/sparc-sun-solaris2.11/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

and config.log reveals:

configure:2590: checking for suffix of object files
configure:2611: /vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/./gcc/xgcc 
-B/vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/./gcc/ 
-B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/ 
-isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem 
/vol/gcc/sparc-sun-solaris2.11/sys-include -c -g -O2conftest.c >&5
conftest.c:12: internal compiler error: Bus Error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:2614: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:2627: error: in 
`/vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/sparc-sun-solaris2.11/libgcc':
configure:2629: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

Running cc1 -O2 conftest.i gives

Program received signal SIGSEGV, Segmentation fault.
grokdeclarator (declarator=0x8bf240, declspecs=0x8bf1e8, decl_context=NORMAL, 
initialized=1 '\001', width=0x0, decl_attrs=0xffbff454, 
deprecated_state=DEPRECATED_NORMAL) at /vol/gcc/src/gcc-dist/gcc/c-decl.c:4194
(gdb) where
#0  grokdeclarator (declarator=0x8bf240, declspecs=0x8bf1e8, 
decl_context=NORMAL, initialized=1 '\001', width=0x0, decl_attrs=0xffbff454, 
deprecated_state=DEPRECATED_NORMAL) at /vol/gcc/src/gcc-dist/gcc/c-decl.c:4194
#1  0x000b3340 in start_function (declspecs=0x8bf1e8, declarator=0x8bf240, 
attributes=0x0) at /vol/gcc/src/gcc-dist/gcc/c-decl.c:6096
#2  0x0010f964 in c_parser_declaration_or_fndef (parser=0xff01d720, fndef_ok=1 
'\001', empty_ok=, nested=0 '\0', start_attr_ok=) at /vol/gcc/src/gcc-dist/gcc/c-parser.c:1278
#3  0x00114574 in c_parse_file () at /vol/gcc/src/gcc-dist/gcc/c-parser.c:979
#4  0x000f7470 in c_common_parse_file (set_yydebug=0) at 
/vol/gcc/src/gcc-dist/gcc/c-opts.c:1239
#5  0x003c40c0 in toplev_main (argc=, argv=) at /vol/gcc/src/gcc-dist/gcc/toplev.c:968
#6  0x00097e54 in _start ()

Looks like a code generation bug to me.  I'll try to start a reghunt asap.

Btw., i386-pc-solaris2.10 is also broken for me, this time while
configuring stage3 libgcc ;-(  Same is true for alpha-dec-osf5.1b and
mips-sgi-irix6.5, so all four of my platforms got broken during the last
for weeks while I was on vacation.

Rainer

-- 
-
Rainer Orth, Faculty of Technology, Bielefeld University

Confusion in pt.c

[Ian Lance Taylor]

Hi Doug, Jason suggested that I write to you about this.  There seems
to be some confusion in the code in cp/pt.c between enum
unification_kind_t (DEDUCE_xxx) and a bitmask of UNIFY_ALLOW_xxx
values.  The parameters are named "strict" for all functions, but in
some cases they are unification_kind_t and in some cases they are int.

The collision happens in unify_pack_expansion.  unify calls
unify_pack_expansion with a bitmask.  type_unification_real calls
unify_pack_expansion with a unification_kind_t.  Within
unify_pack_expansion, I see this:

int arg_strict = strict;
...
if (call_args_p)
  {
...
switch (strict)
  {
  case DEDUCE_CALL:
sub_strict = (UNIFY_ALLOW_OUTER_LEVEL 
  | UNIFY_ALLOW_MORE_CV_QUAL
  | UNIFY_ALLOW_DERIVED);
...
  }
...
arg_strict = sub_strict;
...
  }
...
if (unify (tparms, targs, parm, arg, arg_strict))
  return 1;

In other words, in the switch statement the parameter strict is
treated as a unification_kind_t.  arg_strict is set to either a
unification_kind_t (call_args_p false) or a UNIFY_ALLOW bitmask
(call_args_p true).  Either way, it is passed on to unify.

It's remotely possible that this code is working as intended.  But it
sure looks wrong.

Ian

Re: Please, do not use the merged revisions log as the commit message when merging

[John Freeman]

Christopher Faylor wrote:

On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
  

Daniel Berlin wrote:



It's listed on the wiki that explains how to maintain branches :)
  
  
I had no idea such a wiki even existed.  It would really help future 
contributors, I'm sure, if, perhaps during copyright assignment, there were 
some sort of "introduction" process that clearly communicated policies.  
Thank you for the heads up.



But, you did do it again, just a little while ago.
  
No, I didn't.  I have made one commit in the past week, with a one-liner 
log message.  This morning I used Mr. Lopez-Ibanez's advice in his 
earlier post, number 148771, entitled "broken svn commit logs and how to 
fix them" and changed the log message for revision 139145.  I haven't 
done a merge since the last time this issue came up.


- John

Re: Bootstrap failure on sparc-sun-solaris2.10

[Andreas Tobler]

Rainer Orth wrote:


Looks like a code generation bug to me.  I'll try to start a reghunt asap.


Start around the 25/26th of August. IRA.

Since then it is borked.

Andreas

Re: New assert in haifa-sched.c

[Adam Nemet]

Maxim Kuvyrkov writes:
> Yes, the assert is really checking exactly that.  Several pieces of 
> haifa-sched.c assume that the instruction has been recognized during 
> scheduler initialization to speed up checking if instruction is normal 
> or some kind of use/clobber/asm.

Thanks for the info but I can't seem to find the code where this is supposed
to be happening.  Can you point me to the code?

Adam

Re: Bootstrap failure on sparc-sun-solaris2.10

[H.J. Lu]

On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler <[EMAIL PROTECTED]> wrote:
> Rainer Orth wrote:
>
>> Looks like a code generation bug to me.  I'll try to start a reghunt asap.
>
> Start around the 25/26th of August. IRA.
>
> Since then it is borked.
>

Can you try ira-merge branch? It has all IRA bug fixes without non-IRA
changes.

-- 
H.J.

Re: Please, do not use the merged revisions log as the commit message when merging

[Daniel Berlin]

I'll commit your patch.

On Fri, Sep 5, 2008 at 12:42 PM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/9/5 Christopher Faylor <[EMAIL PROTECTED]>:
>> On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
>>> Daniel Berlin wrote:
>>>
 It's listed on the wiki that explains how to maintain branches :)

>>> I had no idea such a wiki even existed.  It would really help future
>>> contributors, I'm sure, if, perhaps during copyright assignment, there were
>>> some sort of "introduction" process that clearly communicated policies.
>>> Thank you for the heads up.
>>
>> But, you did do it again, just a little while ago.
>>
>> Please stop doing that!  You're swamping gcc.gnu.org and causing unnecessary
>> work for me.
>>
>> I will be instituting some safeguards against this kind of mail-bombing going
>> forward but, nevertheless, this really should not be a common occurrence.
>
> Please Christopher, feel free to take my patch at here, modify it,
> test it and ping whoever is responsible to review such changes:
> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01972.html
>
> Unfortunately, I cannot work on GCC at the moment, so I cannot do it myself.
>
> Cheers,
>
> Manuel.
>

Re: Bootstrap failure on sparc-sun-solaris2.10

[Andreas Tobler]

H.J. Lu wrote:

On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler <[EMAIL PROTECTED]> wrote:

Rainer Orth wrote:


Looks like a code generation bug to me.  I'll try to start a reghunt asap.

Start around the 25/26th of August. IRA.

Since then it is borked.



Can you try ira-merge branch? It has all IRA bug fixes without non-IRA
changes.


How is it named? ira-merge? If, I can't find it on 
http://gcc.gnu.org/svn.html.


Thanks,
Andreas

Re: Bootstrap failure on sparc-sun-solaris2.10

[H.J. Lu]

On Fri, Sep 5, 2008 at 12:36 PM, Andreas Tobler <[EMAIL PROTECTED]> wrote:
> H.J. Lu wrote:
>>
>> On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Rainer Orth wrote:
>>>
 Looks like a code generation bug to me.  I'll try to start a reghunt
 asap.
>>>
>>> Start around the 25/26th of August. IRA.
>>>
>>> Since then it is borked.
>>>
>>
>> Can you try ira-merge branch? It has all IRA bug fixes without non-IRA
>> changes.
>
> How is it named? ira-merge? If, I can't find it on
> http://gcc.gnu.org/svn.html.
>

It is a temporary branch, branches/ira-merge, to track
IRA related problems.

-- 
H.J.

Re: Bootstrap failure on sparc-sun-solaris2.10

[Andreas Tobler]

H.J. Lu wrote:

Can you try ira-merge branch? It has all IRA bug fixes without non-IRA
changes.

How is it named? ira-merge? If, I can't find it on
http://gcc.gnu.org/svn.html.



It is a temporary branch, branches/ira-merge, to track
IRA related problems.


Thanks, co right now.

Andreas

Re: New assert in haifa-sched.c

[Maxim Kuvyrkov]

Adam Nemet wrote:

Maxim Kuvyrkov writes:
Yes, the assert is really checking exactly that.  Several pieces of 
haifa-sched.c assume that the instruction has been recognized during 
scheduler initialization to speed up checking if instruction is normal 
or some kind of use/clobber/asm.


Thanks for the info but I can't seem to find the code where this is supposed
to be happening.  Can you point me to the code?


I'm not 100% sure about current state of things, considering recent 
merge of sel-sched, but before that it was:


set_priorities() -> priority() -> dep_cost() -> recog_memoized().

--
Maxim

Re: New assert in haifa-sched.c

[Adam Nemet]

Maxim Kuvyrkov writes:
> I'm not 100% sure about current state of things, considering recent 
> merge of sel-sched, but before that it was:
> 
> set_priorities() -> priority() -> dep_cost() -> recog_memoized().

I don't think that was the case for all insns even before the patch.  The only
new thing is the assert which now catches this.

If the consumer is an asm just like in gcc.dg/tree-ssa/stdarg-2.c:f10() then
we would not call recog on the producer inside dep_cost*.

The patch below fixes the issue for me.  I am going to test this if it looks
good to people.

Adam

Index: haifa-sched.c
===
--- haifa-sched.c   (revision 139918)
+++ haifa-sched.c   (working copy)
@@ -646,7 +646,8 @@ insn_cost (rtx insn)
 
 /* Compute cost of dependence LINK.
This is the number of cycles between instruction issue and
-   instruction results.  */
+   instruction results.  We also use this function to call
+   recog_memoized on all insns.  */
 int
 dep_cost_1 (dep_t link, dw_t dw)
 {
@@ -657,7 +658,10 @@ dep_cost_1 (dep_t link, dw_t dw)
  This allows the computation of a function's result and parameter
  values to overlap the return and call.  */
   if (recog_memoized (used) < 0)
-cost = 0;
+{
+  cost = 0;
+  recog_memoized (DEP_PRO (link));
+}
   else
 {
   rtx insn = DEP_PRO (link);
@@ -2305,6 +2309,8 @@ choose_ready (struct ready_list *ready, 
  {
insn = ready_element (ready, i);
 
+   /* If this insn is recognizable we should have already
+  recognized it in dep_cost_1.  */
gcc_assert (INSN_CODE (insn) >= 0
|| recog_memoized (insn) < 0);
 

Re: Bootstrap failure on sparc-sun-solaris2.10

[Andreas Tobler]

H.J. Lu wrote:

On Fri, Sep 5, 2008 at 12:36 PM, Andreas Tobler <[EMAIL PROTECTED]> wrote:

H.J. Lu wrote:

On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler <[EMAIL PROTECTED]>
wrote:

Rainer Orth wrote:


Looks like a code generation bug to me.  I'll try to start a reghunt
asap.

Start around the 25/26th of August. IRA.

Since then it is borked.


Can you try ira-merge branch? It has all IRA bug fixes without non-IRA
changes.

How is it named? ira-merge? If, I can't find it on
http://gcc.gnu.org/svn.html.



It is a temporary branch, branches/ira-merge, to track
IRA related problems.


Same issue.
Andreas

Re: Bootstrap failure on sparc-sun-solaris2.10

[H.J. Lu]

On Fri, Sep 5, 2008 at 2:43 PM, Andreas Tobler <[EMAIL PROTECTED]> wrote:
> H.J. Lu wrote:
>>
>> On Fri, Sep 5, 2008 at 12:36 PM, Andreas Tobler <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> H.J. Lu wrote:

 On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler
 <[EMAIL PROTECTED]>
 wrote:
>
> Rainer Orth wrote:
>
>> Looks like a code generation bug to me.  I'll try to start a reghunt
>> asap.
>
> Start around the 25/26th of August. IRA.
>
> Since then it is borked.
>
 Can you try ira-merge branch? It has all IRA bug fixes without non-IRA
 changes.
>>>
>>> How is it named? ira-merge? If, I can't find it on
>>> http://gcc.gnu.org/svn.html.
>>>
>>
>> It is a temporary branch, branches/ira-merge, to track
>> IRA related problems.
>>
> Same issue.

Does trunk bootstrap with revision 139589?


-- 
H.J.

Re: Bootstrap failure on sparc-sun-solaris2.10

[Andreas Tobler]

H.J. Lu wrote:


It is a temporary branch, branches/ira-merge, to track
IRA related problems.


Same issue.


Does trunk bootstrap with revision 139589?



No, gcc version 4.4.0 20080905 (experimental) [trunk revision 140042] (GCC)

Andreas

Re: Bootstrap failure on sparc-sun-solaris2.10

[H.J. Lu]

On Fri, Sep 5, 2008 at 2:57 PM, Andreas Tobler <[EMAIL PROTECTED]> wrote:
> H.J. Lu wrote:
>
>>>> It is a temporary branch, branches/ira-merge, to track
>>>> IRA related problems.
>>>>
>>> Same issue.
>>
>> Does trunk bootstrap with revision 139589?
>>
>>
> No, gcc version 4.4.0 20080905 (experimental) [trunk revision 140042] (GCC)
>

If trunk was broken at revision 139589, your problem isn't
related to IRA since IRA was merged at revision 139590.


-- 
H.J.

gcc-4.4-20080905 is now available

[gccadmin]

Snapshot gcc-4.4-20080905 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080905/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 140047

You'll find:

gcc-4.4-20080905.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.4-20080905.tar.bz2 C front end and core compiler

gcc-ada-4.4-20080905.tar.bz2  Ada front end and runtime

gcc-fortran-4.4-20080905.tar.bz2  Fortran front end and runtime

gcc-g++-4.4-20080905.tar.bz2  C++ front end and runtime

gcc-java-4.4-20080905.tar.bz2 Java front end and runtime

gcc-objc-4.4-20080905.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.4-20080905.tar.bz2The GCC testsuite

Diffs from 4.4-20080829 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Please, do not use the merged revisions log as the commit message when merging

[Christopher Faylor]

On Fri, Sep 05, 2008 at 01:34:08PM -0500, John Freeman wrote:
> Christopher Faylor wrote:
>> On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
>>   
>>> Daniel Berlin wrote:
>>>
>>> 
 It's listed on the wiki that explains how to maintain branches :)
 
>>> I had no idea such a wiki even existed.  It would really help future 
>>> contributors, I'm sure, if, perhaps during copyright assignment, there 
>>> were some sort of "introduction" process that clearly communicated 
>>> policies.  Thank you for the heads up.
>>> 
>>
>> But, you did do it again, just a little while ago.
>>   
>No, I didn't.  I have made one commit in the past week, with a
>one-liner log message.  This morning I used Mr.  Lopez-Ibanez's advice
>in his earlier post, number 148771,

I don't know what post number 148771 is (it's 2008, we can use URLs
these days) but

>entitled "broken svn commit logs and how to fix them" and changed the
>log message for revision 139145.  I haven't done a merge since the last
>time this issue came up.

I'm not making this up:

Subject: Bug 31754
Date: Fri, 05 Sep 2008 14:39:56 -
To: gcc-bugzilla
From: jfreeman

Author: jfreeman
Revision: 139145
Modified property: svn:log

Modified: svn:log at Fri Sep  5 14:39:56 2008
---=
---
--- svn:log (original)
+++ svn:log Fri Sep  5 14:39:56 2008
@@ -1,19740 +1,1 @@
-Merged revisions 136194,136196,136200,136209,136215-136217,136221-136222,1=
36229,136235-136239,136242,136247,136249,136251-136254,136266,136273,136276=
-136277,136280,136282-136283,136291-136297,136301-136304,136308,136311,1363=
14-136315,136319-136323,136329,136331,136344,136348,136351,136355,136359-13=
6360,136362,136372,136374,136376-136378,136383,136386,136389,136395,136406,=
136416,136421,136423,136425,136427-136428,136431,136433-136435,136437-13643=
8,136485-136486,136491,136494,136497-136498,136503,136506,136513,136517-136=
518,136532,136534,136536-136537,136539-136542,136544-136547,136551,136554-1=
36555,136561-136563,136566-136569,136574,136576,136578,136580,136583,136585=
,136590,136596,136600-136602,136604-136605,136609,136615,136617,136619,1366=
32,136636,136639,136641,136645,136647-136651,136653-136655,136657-136658,13=
etc.

This exhibited the same bounce behavior that we saw last time.