GCC 3.3

GCC 3.3

[Mark Mitchell]

As of 5PM PST tomorrow, all non-documentation changes to the 3.3 branch
will require my explicit approval.

I plan to make the first prerelease tarball shortly thereafter.

In my judgement, the current set of regressions against 3.3 contain no
show-stoppers.  There are certainly bugs that would ideally be fixed,
but I do not see anything that looks particularly worse than any other
release of GCC -- and there are a ton of fixes and improvements.

If you know of a regression for which you think we should hold the
release:

(1) Make sure that there is an open, high-priority PR for your problem
with 3.3 in the title.  If there is not such a PR, create one.  Do not
send me email before creating a PR; I cannot keep track of such emails.

(2) After making sure that a PR exists, tell me the number of the PR,
and why you think it is critically important to be fixed.  If there is a
patch available, please tell me that as well.  Holding up the release,
for a PR for which no patch is available, isn't very likely to happen;
you'll have to make a very strong argument.

(3) If I indicate that the PR is not worth holding the release, and you
believe otherwise, let me know; I will forward your request to the GCC
Steering Committee.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Kaveh R. Ghazi]

 > In my judgement, the current set of regressions against 3.3 contain no
 > show-stoppers.

What about compile-time regressions?

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: GCC 3.3

[Steven Bosscher]

Op di 29-04-2003, om 16:44 schreef Kaveh R. Ghazi:
> 
>  > In my judgement, the current set of regressions against 3.3 contain no
>  > show-stoppers.
> 
> What about compile-time regressions?

Seems a bit too late to try and take care of that now, don't you think? 

Gerald and others have shown, there is no single patch or a small set of
patches that we can blame the slowdown on; instead GCC consistently
slowed down over a period that spans at least two years: 3.2 was slower
than 3.1, which in turn was slower than 3.0, etc.

So those compile time regressions will not be fixed in a matter of days,
and weeks or months seems unacceptable.  Let's please just put out 3.3
and move on to make 3.4 a much better (includes: faster) compiler than
3.3.

Besides, your GC params patch compensates for most of the slowdown.   
GCC 3.3 actually is a bit faster than 3.2 for the code I've tried it
on.  Only C++ really is somewhat slower.

Greetz
Steven




> 
> --
> Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-04-29 at 07:44, Kaveh R. Ghazi wrote:
> 
>  > In my judgement, the current set of regressions against 3.3 contain no
>  > show-stoppers.
> 
> What about compile-time regressions?

Yes, there are some.  There are some progressions, too.

Some of the ideas I have are too invasive for the release branch; for
example, I want to go another round on the exceptions/inlining
interaction, but that's probably not a 3.3 change.

Fundamentally, I don't think there's much more we can do without just
waiting around hoping someone will fix things.  

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Scott Robert Ladd]

Mark Mitchell wrote:
> As of 5PM PST tomorrow, all non-documentation changes to the 3.3 branch
> will require my explicit approval.

Good move. I'm using the 04/21 snapshot of 3.3 at the moment; my code
thinks it is very solid.

I've been holding off publishing my next set of gcc-vs-Intel benchmarks
(a new test suite) until 3.3 is out. I'm also doing a feature-by-feature
comparison for ia32 developers -- so comparing gcc 3.3. against Intel
7.1 seems logical.

..Scott

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)

Compilation time (was Re: GCC 3.3)

[Matt Austern]

On Tuesday, April 29, 2003, at 09:27 AM, Mark Mitchell wrote:

> On Tue, 2003-04-29 at 07:44, Kaveh R. Ghazi wrote:
>>
>>> In my judgement, the current set of regressions against 3.3 contain 
>>> no
>>> show-stoppers.
>>
>> What about compile-time regressions?
>
> Yes, there are some.  There are some progressions, too.
>
> Some of the ideas I have are too invasive for the release branch; for
> example, I want to go another round on the exceptions/inlining
> interaction, but that's probably not a 3.3 change.
>
> Fundamentally, I don't think there's much more we can do without just
> waiting around hoping someone will fix things.

I agree that compilation time regressions shouldn't be a reason to 
delay 3.3.  That's why I've changed the subject line: I don't think 
this discussion is really relevant to the 3.3 release.  (Although we 
might want to consider applying the patch Gaby posted a couple days 
ago, considering that his work is already done.)

I also agree we should make compilation time a major goal for 3.4.  One 
implication: if this is a major goal, then it's too important to be 
left just to the people who care about compilation time.  One thing 
we've observed at Apple, and I hope people on this list have noticed it 
too, is that performance just leaks away if you're not looking at it.  
Everybody should be thinking about the performance implications of 
their changes, and everyone should be measuring.  Finally, everybody 
should be concerned about small regressions, not just large ones.  A 2% 
performance regression may not seem like much, but if you check in a 
change that causes a 2% regression then you've just put a new work item 
on someone else's queue: find another change to get back that lost 
time.  It doesn't take very many small regressions to make up a 
noticeable degradation.

			--Matt

Re: Compilation time (was Re: GCC 3.3)

[Gabriel Dos Reis]

Matt Austern <austern@apple.com> writes:

[...]

| I agree that compilation time regressions shouldn't be a reason to
| delay 3.3.  That's why I've changed the subject line: I don't think
| this discussion is really relevant to the 3.3 release.  (Although we
| might want to consider applying the patch Gaby posted a couple days
| ago, considering that his work is already done.)

I have considered ways in which I could do more (and still acceptable)
progressions on that topic for 3.3 -- that partly explains why it
took me so loong to return to you -- but most of the alterntives I
explored turned out to be invasive :-(

That, im my opinion, hilights a major problem about GCC: lack
modularity and abstractions.  Anyway, I've noted that people like Zack
are putting more modularity and abstractions in the compiler (and
removing junks) and I think their works should be thanked and
encouraged. 

I believe that there are many opportunities to improve the name lookup
machinerry with the effect of improving compile time.  Template
instantiations in cc1plus is also a good candidate.

| I also agree we should make compilation time a major goal for 3.4.

This also implies that we have a re-worked release process.

| One implication: if this is a major goal, then it's too important to
| be left just to the people who care about compilation time.

100% agreed.

-- Gaby

Re: Compilation time (was Re: GCC 3.3)

[Daniel Berlin]

>
> I also agree we should make compilation time a major goal for 3.4.  
> One implication: if this is a major goal, then it's too important to 
> be left just to the people who care about compilation time.  One thing 
> we've observed at Apple, and I hope people on this list have noticed 
> it too, is that performance just leaks away if you're not looking at 
> it.  Everybody should be thinking about the performance implications 
> of their changes, and everyone should be measuring.  Finally, 
> everybody should be concerned about small regressions, not just large 
> ones.  A 2% performance regression may not seem like much, but if you 
> check in a change that causes a 2% regression then you've just put a 
> new work item on someone else's queue: find another change to get back 
> that lost time.  It doesn't take very many small regressions to make 
> up a noticeable degradation.
>

While we already have people doing nightly testing of performance of 
generated code, maybe we need some nightly testing of compilation speed 
on some representative set of code.
A weekly nag report that tells us how much performance has 
improved/degraded on the various tests that week/month/since last 
release would be nice, too.

> 			--Matt
>

Re: Compilation time (was Re: GCC 3.3)

[Diego Novillo]

On Tue, 2003-04-29 at 13:18, Daniel Berlin wrote:

> While we already have people doing nightly testing of performance of 
> generated code, maybe we need some nightly testing of compilation speed 
> on some representative set of code.
>
We have that too.

http://people.redhat.com/dnovillo/spec2000/gcc/gcc-stats.html
http://people.redhat.com/dnovillo/spec2000/gcc/global-build-secs_elapsed.html

It doesn't generate complaints when there are regressions, though.


Diego.

Re: GCC 3.3

[Laurent Guerby]

I just submitted PR ada/10546 for the tasking change
to get things working on all LinuxThread version
included those shipped with Red Hat Linux 9.

The 3.2.3 patch applies cleanly to 3.3 since
the file 5iosinte.ads hasn't changed between 3.2 and 3.3
(but for RCS Tag removal).

I need to test it on older glibc Linux systems if it
is okayed in principle for 3.3, I have access
to a slow machine so this will take a while,
let me know of your decision.

-- 
Laurent Guerby <guerby@acm.org>

Re: GCC 3.3

[Mark Mitchell]

> I need to test it on older glibc Linux systems if it
> is okayed in principle for 3.3, I have access
> to a slow machine so this will take a while,
> let me know of your decision.

It would be good to get this in, so get started on your testing ASAP.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: Compilation time (was Re: GCC 3.3)

[Phil Edwards]

I've added timing to the autocrasher.  Look for "TIME::" followed by real
(wall clock), user, and system seconds in the logs.  It'll start appearing
in the next 31 minutes to 7 days, depending on which build you're examining.

Pulling the time out of the logs, graphing it, possibly sending nag mail,
etc, will start later.

This will give us nightly granularity.

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Compilation time (was Re: GCC 3.3)

[Mike Stump]

On Tuesday, April 29, 2003, at 12:30 PM, Phil Edwards wrote:
> I've added timing to the autocrasher.  Look for "TIME::" followed by 
> real
> (wall clock), user, and system seconds in the logs.

Please output it as

PERF: %f <arbitrary unique string that explains it>

Analysis tools can then key up on these lines.  There should be one 
line per number, and the number of such lines should be stable, and the 
unique text should be stable.
The entire performance testsuite will follow this one standard, compile 
time, generated code quality, size of generated code...  Bigger == 
worse.  units are arbitrary, but can be things like, seconds, bytes, 
clock ticks, load stalls, cache misses...

Thanks.

Re: GCC 3.3

[Arnaud Charlet]

> I just submitted PR ada/10546 for the tasking change
> to get things working on all LinuxThread version
> included those shipped with Red Hat Linux 9.

Note that I've just included a fix for redhat 9 tasking on act's tree,
so I'd suggest you pick up this change (tomorrow, after the mirror) instead,
at least for the HEAD.

For the 3.3 branch, your previous patch is fine (now, you may want for
consistency to use the same approach on both branches).

Arno

Re: Compilation time (was Re: GCC 3.3)

[Matt Austern]

On Tuesday, April 29, 2003, at 12:30  PM, Phil Edwards wrote:

> I've added timing to the autocrasher.  Look for "TIME::" followed by 
> real
> (wall clock), user, and system seconds in the logs.  It'll start 
> appearing
> in the next 31 minutes to 7 days, depending on which build you're 
> examining.

Terrific idea! How are you doing the timing?  The reason I ask is that 
I've found you need to be pretty careful to get reproducible results.

I've got some specific suggestions, some of which you've probably 
thought of already:

  1. Compile an unchanging piece of source code.  Compiler bootstrap is 
a poor test, for example, because you're never timing the same thing 
twice.
  2. Choose a test case that takes at least a minute or so to compile.  
(Not that there has to be any single translation unit that takes that 
long, mind you: a test case that consists of a number of smallish 
translation units is fine.)  Rationale: too short and you find that 
your results are dominated by noise.
  3. Just to state the obvious, even though I know you know this 
already: run on an unloaded system.
  4. Compile the test case five times, and throw away the first result.  
Rationale: at least on some OSs, the result the first time you do the 
compilation is too noisy.  It's dominated by uninteresting details of 
what the caches happened to look like before you started the test.  
("Five" is slightly arbitrary, but you should at least have three 
results that you're not throwing away.)
  5. You've now timed the test case four times.  Report both the mean 
and the standard deviation.  Rationale: reporting the standard 
deviation lets people known how reproducible the results really are.

I think that if you follow these suggestions you'll be able to catch 
sub-1% regressions on a daily granularity, which would be really 
valuable.

			--Matt

Re: Compilation time (was Re: GCC 3.3)

[Timothy J. Wood]

   Maybe this is obvious, but I'd also add:

6.  Don't use 'configure', 'make' or any other complex glue code in the 
timing tests.  You want to test the compiler time, not the whole build 
process.  This will help in detecting small variations in compiler 
speed by making the percentage of time spent in the compiler larger.  
If you want to use some project for testing that builds using using a  
bunch of glue, maybe do it once via the glue and capture the emitted 
commands, building a trivial shell script out of them.

-tim


On Tuesday, April 29, 2003, at 05:30  PM, Matt Austern wrote:

> On Tuesday, April 29, 2003, at 12:30  PM, Phil Edwards wrote:
>
>> I've added timing to the autocrasher.  Look for "TIME::" followed by 
>> real
>> (wall clock), user, and system seconds in the logs.  It'll start 
>> appearing
>> in the next 31 minutes to 7 days, depending on which build you're 
>> examining.
>
> Terrific idea! How are you doing the timing?  The reason I ask is that 
> I've found you need to be pretty careful to get reproducible results.
>
> I've got some specific suggestions, some of which you've probably 
> thought of already:
>
>  1. Compile an unchanging piece of source code.  Compiler bootstrap is 
> a poor test, for example, because you're never timing the same thing 
> twice.
>  2. Choose a test case that takes at least a minute or so to compile.  
> (Not that there has to be any single translation unit that takes that 
> long, mind you: a test case that consists of a number of smallish 
> translation units is fine.)  Rationale: too short and you find that 
> your results are dominated by noise.
>  3. Just to state the obvious, even though I know you know this 
> already: run on an unloaded system.
>  4. Compile the test case five times, and throw away the first result. 
>  Rationale: at least on some OSs, the result the first time you do the 
> compilation is too noisy.  It's dominated by uninteresting details of 
> what the caches happened to look like before you started the test.  
> ("Five" is slightly arbitrary, but you should at least have three 
> results that you're not throwing away.)
>  5. You've now timed the test case four times.  Report both the mean 
> and the standard deviation.  Rationale: reporting the standard 
> deviation lets people known how reproducible the results really are.
>
> I think that if you follow these suggestions you'll be able to catch 
> sub-1% regressions on a daily granularity, which would be really 
> valuable.
>
> 			--Matt

Re: Compilation time (was Re: GCC 3.3)

[Gabriel Dos Reis]

Matt Austern <austern@apple.com> writes:

| On Tuesday, April 29, 2003, at 12:30  PM, Phil Edwards wrote:
| 
| > I've added timing to the autocrasher.  Look for "TIME::" followed by
| > real
| > (wall clock), user, and system seconds in the logs.  It'll start
| > appearing
| > in the next 31 minutes to 7 days, depending on which build you're
| > examining.
| 
| Terrific idea!

Indeed!

[...]

| I've got some specific suggestions, some of which you've probably
| thought of already:
| 
|   1. Compile an unchanging piece of source code.  Compiler bootstrap
| is a poor test, for example, because you're never timing the same
| thing twice.

Completely agreed; although bootstrapping the compiler might give
some indication on slowdown :-)  

There are some free software out there known to trash the compiler
(e.g. C++ front-end) to death. Qt and KDE sources are popular examples
-- compiling Qt without -ftime-report takes about an hour (and about
thrice that time with -ftime-report) on my pentium 4 (2GHz) box
running a GNU/Linux system.  

[...]

|   3. Just to state the obvious, even though I know you know this
| already: run on an unloaded system.
|   4. Compile the test case five times, and throw away the first
| result.  Rationale: at least on some OSs, the result the first time
| you do the compilation is too noisy.  It's dominated by uninteresting
| details of what the caches happened to look like before you started
| the test.  ("Five" is slightly arbitrary, but you should at least have
| three results that you're not throwing away.)

I completely agree with both points.  At least, they match my
experience with the name lookup issue.  I don't know if Phil is
planning to monitor timing with -ftime-report, but I think that would
be a valuable information.

-- Gaby

Re: Compilation time (was Re: GCC 3.3)

[Gabriel Dos Reis]

"Timothy J. Wood" <tjw@omnigroup.com> writes:

| 6.  Don't use 'configure', 'make' or any other complex glue code in
| the timing tests.

I've found GCC's -ftime-report or -fstats might useful, although
inaccurate in some areas like time spent in parsing.

-- Gaby

Re: GCC 3.3

[Gerald Pfeifer]

On Tue, 29 Apr 2003, Steven Bosscher wrote:
>> What about compile-time regressions?
> Seems a bit too late to try and take care of that now, don't you think?
>
> Gerald and others have shown, there is no single patch or a small set of
> patches that we can blame the slowdown on; instead GCC consistently
> slowed down over a period that spans at least two years: 3.2 was slower
> than 3.1, which in turn was slower than 3.0, etc.

There are two major sources of frustration here, affecting at least me
(as a user) and Mark (as maintainer and release manager).

> So those compile time regressions will not be fixed in a matter of days,
> and weeks or months seems unacceptable.  Let's please just put out 3.3
> and move on to make 3.4 a much better (includes: faster) compiler than
> 3.3.

1. I reported these performance regressions before the release of GCC 3.0,
   about two years ago

     http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3083

   and spent a significant amount of time (surely several man days)
   following this issue, as have others including yourself and Kaveh).

   Still, now close to GCC 3.3, the situation is as bad as:

      http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=8361

                    -O0         -O1          -O2        -O3
       GCC 3.0.4    27.95       44.52        56.57      56.48
      3.2-branch    29.87 +7%   54.28 +22%   70.95 +25% 75.29 +33%
      3.3-branch    29.09 +4%   57.11 +30%   78.99 +40% 81.61 +44%

   (and this completely ignores GCC 2.95, which was _vastly_ faster).

   > Only C++ really is somewhat slower.

   That's an euphemism.

2. Mark _has_ contributed quite a couple of performance improvements,
   (and so have others).

   But just because he is release manager and C++ maintainer, nobody can
   sensibly demand that he fixes all performance issues showing up from
   C++ code by himself; even more so if many advances of his are more
   than offset by the creeping slowdown throughout the compiler.

So, in the end, I suppose that currently both Mark and myself are somehow
frustrated (at least that's how I understood his reply).

Obviously, the picture is not as simple as drafted above, many others have
contributed most welcome performance improvements (even if in the end, we
lost), and some of the slowdowns were for correctness and optimization
(even if neither applied to my code at least).

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Compilation time (was Re: GCC 3.3)

[Phil Edwards]

Somewhat re-ording your suggestions.


On Tue, Apr 29, 2003 at 05:30:22PM -0700, Matt Austern wrote:
>  1. Compile an unchanging piece of source code.

Anything in particular?  I don't much care what, but its build time
multiplied by 5 needs to not be hellishly long.  (The machine is used for
other things; and of course is can't be doing any of those other things
while these tests are running.)

I thought about building SPEC2000, since that seems to be fast ('prox
5 minutes), but I don't have enough spare time in the day to also /run/
SPEC2000 ('prox 1 to 2 hours), which is sort of the whole point of SPEC.


> Terrific idea! How are you doing the timing?  The reason I ask is that 
> I've found you need to be pretty careful to get reproducible results.
[...]
>  4. Compile the test case five times, and throw away the first result.  
> Rationale: at least on some OSs, the result the first time you do the 
> compilation is too noisy.  It's dominated by uninteresting details of 
> what the caches happened to look like before you started the test.  
> ("Five" is slightly arbitrary, but you should at least have three 
> results that you're not throwing away.)
>  5. You've now timed the test case four times.  Report both the mean 
> and the standard deviation.  Rationale: reporting the standard 
> deviation lets people known how reproducible the results really are.

I have some framework scripts that do almost exactly all this.  Adapting them
from running simulations to building some software package should be simple.
Although I'm considering just throwing them out.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Compilation time (was Re: GCC 3.3)

[Phil Edwards]

On Wed, Apr 30, 2003 at 02:53:56AM +0200, Gabriel Dos Reis wrote:
> Matt Austern <austern@apple.com> writes:
> | I've got some specific suggestions, some of which you've probably
> | thought of already:
> | 
> |   1. Compile an unchanging piece of source code.  Compiler bootstrap
> | is a poor test, for example, because you're never timing the same
> | thing twice.
> 
> Completely agreed; although bootstrapping the compiler might give
> some indication on slowdown :-)  

That's what I'm starting with, only because I already had some stuff in
place to examine the output (e.g, what kind of bootstrap failure, for the
nag mail).

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Compilation time (was Re: GCC 3.3)

[Gabriel Dos Reis]

Phil Edwards <phil@jaj.com> writes:

| Somewhat re-ording your suggestions.
| 
| 
| On Tue, Apr 29, 2003 at 05:30:22PM -0700, Matt Austern wrote:
| >  1. Compile an unchanging piece of source code.
| 
| Anything in particular?

I would suggest qt-3.1.1 for C++ sources -- no fancy things though.

-- Gaby

Re: Compilation time (was Re: GCC 3.3)

[Phil Edwards]

On Wed, Apr 30, 2003 at 08:34:05PM +0200, Gabriel Dos Reis wrote:
> Phil Edwards <phil@jaj.com> writes:
> | 
> | Anything in particular?
> 
> I would suggest qt-3.1.1 for C++ sources -- no fancy things though.

The following sentence that you snipped was

                              I don't much care what, but its build time
    multiplied by 5 needs to not be hellishly long.

and in another message, you wrote

    compiling Qt without -ftime-report takes about an hour (and about
    thrice that time with -ftime-report) on my pentium 4 (2GHz) box
    running a GNU/Linux system.

Five hours falls into the hellishly long category.

But there may be hope:  how much time does "no fancy things" shave from
that hour of build time?  If building the non-fancy parts of Qt only takes
10 minutes, then that's a very viable option.

Alternatively, I could dedicate the machine to doing some really long
build five times over, but only once a week.  This may not be as useful;
you guys decide.

This may help:  http://www.devphil.com/build/sched.html


Phil
(Given the wear and tear on the drives that constant bootstrapping causes,
I need to start looking into affordable backups solutions.  *grin*)

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Compilation time (was Re: GCC 3.3)

[Matt Austern]

On Wednesday, April 30, 2003, at 11:28 AM, Phil Edwards wrote:

> Somewhat re-ording your suggestions.
>
>
> On Tue, Apr 29, 2003 at 05:30:22PM -0700, Matt Austern wrote:
>>  1. Compile an unchanging piece of source code.
>
> Anything in particular?  I don't much care what, but its build time
> multiplied by 5 needs to not be hellishly long.  (The machine is used 
> for
> other things; and of course is can't be doing any of those other things
> while these tests are running.)

I don't have any specific suggestion, but I do recommend that you 
choose a C++ project because that's where we've got the most 
complaints.  Mozilla and QT are both obvious, but they'd probably be 
bad for this purpose because a timing run times five would take hours.

One possibility might be (some specific version of) libstdc++.

			--Matt

Re: Compilation time (was Re: GCC 3.3)

[Phil Edwards]

On Tue, Apr 29, 2003 at 05:51:24PM -0700, Timothy J. Wood wrote:
> 
>   Maybe this is obvious, but I'd also add:
> 
> 6.  Don't use 'configure', 'make' or any other complex glue code in the 
> timing tests.  You want to test the compiler time, not the whole build 
> process.  This will help in detecting small variations in compiler 
> speed by making the percentage of time spent in the compiler larger.  

Right.  More to the point, I don't want to spend exclusive time testing
a build process which itself is changing rapidly, and then bill that time
to the compiler.

I do plan on timing the configure step by itself, on the side, just for
additional shared misery.


> If you want to use some project for testing that builds using using a  
> bunch of glue, maybe do it once via the glue and capture the emitted 
> commands, building a trivial shell script out of them.

Either that, or assume that for, e.g., a released package, the Makefile
isn't changing either, and simply ignore the constant overhead.  We're not
looking for absolute numbers, after all, but steady changes.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Compilation time (was Re: GCC 3.3)

[Eric Christopher]

> Five hours falls into the hellishly long category.
> 
> But there may be hope:  how much time does "no fancy things" shave from
> that hour of build time?  If building the non-fancy parts of Qt only takes
> 10 minutes, then that's a very viable option.

How about 20001226-1.c? It takes a while to build and while it's kinda
dependent on a couple of passes in teh compiler, it can take a few mins
to build.

or maybe something out of spu? doesn't it build arbitrarily long
programs?

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Compilation time (was Re: GCC 3.3)

[Diego Novillo]

On Wed, 2003-04-30 at 14:28, Phil Edwards wrote:
> Somewhat re-ording your suggestions.
> 
> 
> On Tue, Apr 29, 2003 at 05:30:22PM -0700, Matt Austern wrote:
> >  1. Compile an unchanging piece of source code.
> 
> Anything in particular?  I don't much care what, but its build time
> multiplied by 5 needs to not be hellishly long.  (The machine is used for
> other things; and of course is can't be doing any of those other things
> while these tests are running.)
> 
I collected a bunch of .i files from the C front end and use that as my
unchanging code base.  It shouldn't take long to compile this 2-3 times
to get a good average.


Diego.

Re: Compilation time (was Re: GCC 3.3)

[Karel Gardas]

On Wed, 30 Apr 2003, Phil Edwards wrote:

> Somewhat re-ording your suggestions.
>
>
> On Tue, Apr 29, 2003 at 05:30:22PM -0700, Matt Austern wrote:
> >  1. Compile an unchanging piece of source code.
>
> Anything in particular?

If you are interested, I can provide you with some files (preprocessed)
for MICO 2.3.9 [1]. Just look at
http://gcc.gnu.org/ml/gcc/2003-02/msg01530.html and choose which you would
like to test. (at least MICO is a bit smaller than both Qt and Mozilla
already suggested)

Cheers,

Karel
[1] http://www.mico.org
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: Compilation time (was Re: GCC 3.3)

[Phil Edwards]

On Wed, Apr 30, 2003 at 12:07:47PM -0700, Eric Christopher wrote:
> 
> or maybe something out of spu? doesn't it build arbitrarily long
> programs?

Why the hell didn't I think of that... spu is one of my favorite utilities.

I'll start playing with it and see what I can get it to, er, spew.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Compilation time (was Re: GCC 3.3)

[Gabriel Dos Reis]

Phil Edwards <phil@jaj.com> writes:

| On Wed, Apr 30, 2003 at 08:34:05PM +0200, Gabriel Dos Reis wrote:
| > Phil Edwards <phil@jaj.com> writes:
| > | 
| > | Anything in particular?
| > 
| > I would suggest qt-3.1.1 for C++ sources -- no fancy things though.
| 
| The following sentence that you snipped was
| 
|                               I don't much care what, but its build time
|     multiplied by 5 needs to not be hellishly long.
| 
| and in another message, you wrote
| 
|     compiling Qt without -ftime-report takes about an hour (and about
|     thrice that time with -ftime-report) on my pentium 4 (2GHz) box
|     running a GNU/Linux system.
| 
| Five hours falls into the hellishly long category.
| 
| But there may be hope:  how much time does "no fancy things" shave from
| that hour of build time?

The "fancy things" was referring to C++ features used in Qt.  The
sources all tend to be made on the same scheme: heavy class hierarchy,
small codes in .cc files, many things at global scope, basic template
usage (well this part may depend on whether you specify -stl or not). 

| If building the non-fancy parts of Qt only takes
| 10 minutes, then that's a very viable option.

Some take less that 10 min, some (very few) more than 10 min.
As I said, they tend to ressemble each other in the set of used
features. 

-- Gaby

Re: Compilation time (was Re: GCC 3.3)

[Paul Koning]

>>>>> "Diego" == Diego Novillo <dnovillo@redhat.com> writes:

 Diego> On Wed, 2003-04-30 at 14:28, Phil Edwards wrote:
 >> Somewhat re-ording your suggestions.
 >> 
 >> 
 >> On Tue, Apr 29, 2003 at 05:30:22PM -0700, Matt Austern wrote: >
 >> 1. Compile an unchanging piece of source code.
 >> 
 >> Anything in particular?  I don't much care what, but its build
 >> time multiplied by 5 needs to not be hellishly long.  (The machine
 >> is used for other things; and of course is can't be doing any of
 >> those other things while these tests are running.)
 >> 
 Diego> I collected a bunch of .i files from the C front end and use
 Diego> that as my unchanging code base.  It shouldn't take long to
 Diego> compile this 2-3 times to get a good average.

I think you need to start from c or c++ files, because that's the real
world scenario and that's what matters to people who are using gcc.

      paul

Re: Compilation time (was Re: GCC 3.3)

[law]

In message <1051729729.15231.712.camel@frodo.toronto.redhat.com>, Diego Novillo
 writes:
 >On Wed, 2003-04-30 at 14:28, Phil Edwards wrote:
 >> Somewhat re-ording your suggestions.
 >> 
 >> 
 >> On Tue, Apr 29, 2003 at 05:30:22PM -0700, Matt Austern wrote:
 >> >  1. Compile an unchanging piece of source code.
 >> 
 >> Anything in particular?  I don't much care what, but its build time
 >> multiplied by 5 needs to not be hellishly long.  (The machine is used for
 >> other things; and of course is can't be doing any of those other things
 >> while these tests are running.)
 >> 
 >I collected a bunch of .i files from the C front end and use that as my
 >unchanging code base.  It shouldn't take long to compile this 2-3 times
 >to get a good average.
FWIW, now that we have C++ working with tree-ssa we should probably
add the .ii files from libstdc++ to at least start looking at how
our changes are affecting C++ compile time.

jeff

Re: Compilation time (was Re: GCC 3.3)

[law]

In message <1051729667.15551.5.camel@ghostwheel.sfbay.redhat.com>, Eric Christo
pher writes:
 >
 >> Five hours falls into the hellishly long category.
 >> 
 >> But there may be hope:  how much time does "no fancy things" shave from
 >> that hour of build time?  If building the non-fancy parts of Qt only takes
 >> 10 minutes, then that's a very viable option.
 >
 >How about 20001226-1.c? It takes a while to build and while it's kinda
 >dependent on a couple of passes in teh compiler, it can take a few mins
 >to build.
Yea, but it's really stressing just a couple key codepaths.  While it's
an interesting test, I don't necessarily think it's representative of
real code.

Qt, Mozilla, POOMA and the like would make much better tests -- even if
it's just some of their shared libraries if the entire packages themselves
are too large.

Jeff

Re: Compilation time (was Re: GCC 3.3)

[Matt Austern]

On Wednesday, April 30, 2003, at 01:18 PM, Paul Koning wrote:

>>>>>> "Diego" == Diego Novillo <dnovillo@redhat.com> writes:
>
>  Diego> On Wed, 2003-04-30 at 14:28, Phil Edwards wrote:
>>> Somewhat re-ording your suggestions.
>>>
>>>
>>> On Tue, Apr 29, 2003 at 05:30:22PM -0700, Matt Austern wrote: >
>>> 1. Compile an unchanging piece of source code.
>>>
>>> Anything in particular?  I don't much care what, but its build
>>> time multiplied by 5 needs to not be hellishly long.  (The machine
>>> is used for other things; and of course is can't be doing any of
>>> those other things while these tests are running.)
>>>
>  Diego> I collected a bunch of .i files from the C front end and use
>  Diego> that as my unchanging code base.  It shouldn't take long to
>  Diego> compile this 2-3 times to get a good average.
>
> I think you need to start from c or c++ files, because that's the real
> world scenario and that's what matters to people who are using gcc.

I agree.  We've found that in some cases preprocessor time can be 
significant.  We've also found that the sum of preprocessing time and 
time to compile a .ii file is greater than the time to compile the .cc 
file to begin with.

			--Matt

Re: GCC 3.3

[Mike Stump]

On Tuesday, April 29, 2003, at 08:16 AM, Steven Bosscher wrote:
> Gerald and others have shown, there is no single patch or a small set 
> of
> patches that we can blame the slowdown on; instead GCC consistently
> slowed down over a period that spans at least two years: 3.2 was slower
> than 3.1, which in turn was slower than 3.0, etc.

For one benchmark we have, between 3.1 and 3.3, there were two patches 
that caused compile time speed regressions, the second was small and 
was eventually fixed or worked around with the physmem patch.  The 
first, was a ~30% speed regression in one tiny little patch.  This bug 
remains unfixed on the 3.3 branch.

Re: GCC 3.3

[Steven Bosscher]

Op wo 30-04-2003, om 21:37 schreef Mike Stump:
> For one benchmark we have, between 3.1 and 3.3, there were two patches 
> that caused compile time speed regressions, the second was small and 
> was eventually fixed or worked around with the physmem patch.  The 
> first, was a ~30% speed regression in one tiny little patch.  This bug 
> remains unfixed on the 3.3 branch.

I think you have us _all_ wondering now: Which patch was that "first
patch" you talk about?  :-)

Greetz
Steven

Re: GCC 3.3

[Mike Stump]

On Wednesday, April 30, 2003, at 12:41 PM, Steven Bosscher wrote:
> Op wo 30-04-2003, om 21:37 schreef Mike Stump:
>> For one benchmark we have, between 3.1 and 3.3, there were two patches
>> that caused compile time speed regressions, the second was small and
>> was eventually fixed or worked around with the physmem patch.  The
>> first, was a ~30% speed regression in one tiny little patch.  This bug
>> remains unfixed on the 3.3 branch.
>
> I think you have us _all_ wondering now: Which patch was that "first
> patch" you talk about?  :-)

http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00530.html

It was much talked about in Feb:

http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01245.html

Re: Compilation time (was Re: GCC 3.3)

[Jack Lloyd]

On Wed, 30 Apr 2003 law@redhat.com wrote:

> Qt, Mozilla, POOMA and the like would make much better tests -- even if
> it's just some of their shared libraries if the entire packages themselves
> are too large.

ACE might work pretty well. The basic ACE library takes ~10-15 minutes to
build on my machine (1.4 Ghz Athlon), and it's large enough to make a good
overall test.
 -Jack

Re: Compilation time

[Zack Weinberg]

Matt Austern <austern@apple.com> writes:

> I agree.  We've found that in some cases preprocessor time can be
> significant.

I'd like to see examples.

> We've also found that the sum of preprocessing time and time to
> compile a .ii file is greater than the time to compile the .cc file
> to begin with.

This is inevitable -- work is done twice.  (Also, generation of the
.ii file is slow, as no one has bothered to make it fast.)

zw

Re: GCC 3.3

[Mark Mitchell]

> 2. Mark _has_ contributed quite a couple of performance improvements,
>    (and so have others).
> 
>    But just because he is release manager and C++ maintainer, nobody can
>    sensibly demand that he fixes all performance issues showing up from
>    C++ code by himself; even more so if many advances of his are more
>    than offset by the creeping slowdown throughout the compiler.
> 
> So, in the end, I suppose that currently both Mark and myself are somehow
> frustrated (at least that's how I understood his reply).

I just don't think that we're going to be able to fix this for 3.3 given
where we presently are.

In practice, we often have a hard time getting people to fix correctness
regressions that they have introduced; compile-time regressions will be
even tougher, and they're tougher to pin on a particular person.  If I
fix a bug, but introduce a 0.25% slowdown, is that a net win or not? 
What if I speed up some piece of generated code by 1%?  When we still
have quadratic algorithms in the compiler, should we worry about my
0.25% slowdown?  Maybe we should invest in fixing those algorithms
instead -- but that requires major work, and we can't expect someone
who's just fixing a bug somewhere to do that.

The good news is that LANL is interested in seeing the C++ compiler run
faster, so Zack and Nathan and I *are* looking at these issues, from a
variety of different angles.

We are lucky in that LANL and Apple (among others, perhaps) are actively
supporting improvements in this area.  

I remain hopeful.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: Compilation time (was Re: GCC 3.3)

[Gerald Pfeifer]

On Wed, 30 Apr 2003, Phil Edwards wrote:
>>  1. Compile an unchanging piece of source code.
> Anything in particular?

What's wrong with
  http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=8361
which a first submitted two years ago (as part of a different PR)?

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Compilation time (was Re: GCC 3.3)

[Phil Edwards]

On Thu, May 01, 2003 at 08:20:12PM +0200, Scott Wheeler wrote:
> On Wednesday 30 April 2003 20:45, Phil Edwards wrote:
> >     compiling Qt without -ftime-report takes about an hour (and about
> >     thrice that time with -ftime-report) on my pentium 4 (2GHz) box
> >     running a GNU/Linux system.
> > 
> > Five hours falls into the hellishly long category.
> 
> Well, that's four hours (1 + 3) not five, but yes that's quite a while.

Five builds.  Each takes one hour.  Five hours.


> However, it really shouldn't take that long.  Qt specifically is built as 
> (primarily) one shared library, plus some tools and plugins.  If you just 
> build that shared library on my machine (1.4 GHz Athlon, Linux) it takes just 
> under 11 minutes of CPU time for a "normal" build of just that shared 
> library.  That roughly doubles to compile all of Qt (tools and plugins, but 
> not examples).

Okay, 11 minutes per build is certainly feasible, so that core library
might be a good test.  I'll add it to the list of possibilities.


Thanks!
Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Compilation time (was Re: GCC 3.3)

[Scott Wheeler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 30 April 2003 20:45, Phil Edwards wrote:

> > I would suggest qt-3.1.1 for C++ sources -- no fancy things though.
 
>     compiling Qt without -ftime-report takes about an hour (and about
>     thrice that time with -ftime-report) on my pentium 4 (2GHz) box
>     running a GNU/Linux system.
> 
> Five hours falls into the hellishly long category.

Well, that's four hours (1 + 3) not five, but yes that's quite a while.

However, it really shouldn't take that long.  Qt specifically is built as 
(primarily) one shared library, plus some tools and plugins.  If you just 
build that shared library on my machine (1.4 GHz Athlon, Linux) it takes just 
under 11 minutes of CPU time for a "normal" build of just that shared 
library.  That roughly doubles to compile all of Qt (tools and plugins, but 
not examples).

Presuming that just this lib could be built in the benchmark and that the 
ratios above hold true, I think that 44 minutes != hellishly long.

This should be a reasonable metric for how C++ is used in the KDE project and 
would hopefully be beneficial to both the GCC folks and the KDE developers 
(who spend on average 14% of our lives staring at GCC's C++ output.  ;-) ).

Cheers,

- -Scott
 
- -- 
I believe that a scientist looking at nonscientific problems is just as dumb 
as the next guy. 
- --Richard Feynman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+sWVfQu0ByfY5QTkRAlTBAJ4jCWZXQ1vmr9JTTC8DEWCjBAY8HgCeMjID
tK3LJvv0GU4AUmHgWD2LrFA=
=PS5B
-----END PGP SIGNATURE-----

Re: GCC 3.3

[Gerald Pfeifer]

On Thu, 30 Apr 2003, Mark Mitchell wrote:
> I just don't think that we're going to be able to fix this for 3.3 given
> where we presently are.

I cannot really disagree, even though we bailed out before 3.0, we
bailed out before 3.1, and now we bail out before 3.3 again.

(The fact that we would be even slower without your various compile-time
improvements based on the examples I provided makes this even worse,
somehow.)

However, I take this as a clear indication that we need to rethink our
release process -- we cannot expect intricate issues like compile-time
performance to be solved on a release-branch, that's the resumé, I'd say,
so we must identify and take care of them before.

> The good news is that LANL is interested in seeing the C++ compiler run
> faster, so Zack and Nathan and I *are* looking at these issues, from a
> variety of different angles.
>
> We are lucky in that LANL and Apple (among others, perhaps) are actively
> supporting improvements in this area.

Good news!

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: GCC 3.3

[Benjamin Kosnik]

>2003-03-28  Albert Chin-A-Young  <china@thewrittenword.com>
>
>	* gcc/fixinc/inclhack.def: Update solaris_mutex_init_1 to
>	work on Solaris 2.5.1.
>
>2003-03-22  DJ Delorie  <dj at redhat dot com>,
>	Bruce Korb  <bkorb at gnu dot org>
>
>	* fixinc/inclhack.def (solaris_mutex_init_1): New; Fix
>	buggy Solaris 2.6 mutex/cond initializers.
>	(solaris_mutex_init): Rename to solaris_mutex_init_2.
>	* fixinc/fixincl.x: Regenerate.
>	* fixinc/tests/base/pthread.h: Update.
>	* fixinc/fixincl.c(initialize): be explicit about the default case
>	and indicate verbose level when being very, very verbose.
>	* fixinc/check.tpl(VERBOSE): provide a means for passing the value in
>
>but none on the 3.3 branch?

You should ask Bruce to queue this for 3.3.1.

-benjamin

Re: GCC 3.3

[Eric Botcazou]

> The problem belongs to the definitions of PTHREAD_MUTEX_INITIALIZER and
> PTHREAD_COND_INITIALIZER in pthread.h in solaris 2.6 .
>
> To solve the problem I added the two following fixes in file
> inclhack.def:
>
> fix = {
>     hackname = solaris26_mutex_init;
>     select = '@\(#\)pthread.h' "[ \t]+1.16+[ \t]+[0-9/]+ SMI";
>     files = pthread.h;
>     c_fix = format;
>     c_fix_arg = "%1{{0},0},{0}%2\n";
>     c_fix_arg = "(^#define[ \t]+PTHREAD_MUTEX_INITIALIZER[ \t]+{[ \t]*)"
>
>                 "0,[ \t]*0" "(,.*)$";
>     test_text =
>     '#ident "@(#)pthread.h 1.16 97/05/05 SMI"'"\n"
>     "#define PTHREAD_MUTEX_INITIALIZER\t{0, 0, 0}[ \t]*\n";
> };
>
>
> fix = {
>     hackname = solaris26_cond_init;
>     select = '@\(#\)pthread.h' "[ \t]+1.16+[ \t]+[0-9/]+ SMI";
>     files = pthread.h;
>     c_fix = format;
>     c_fix_arg = "%1{{0},0}%2\n";
>     c_fix_arg = "(^#define[ \t]+PTHREAD_COND_INITIALIZER[ \t]+{[ \t]*)"
>                 "0" "(,.*)$";
>     test_text =
>     '#ident "@(#)pthread.h 1.16 97/05/05 SMI"'"\n"
>     "#define PTHREAD_COND_INITIALIZER\t{0, 0}[ \t]*\n";
> };
>
> I hope this will help you.

Sure. Many thanks!

I should have remembered this problem... this is PR target/7971.


DJ, what is the status of this PR?

I see this entry in the ChangeLog for 3.2.3:

2003-03-29  Albert Chin-A-Young  <china@thewrittenword.com>
	DJ Delorie  <dj at redhat dot com>,
	Bruce Korb  <bkorb at gnu dot org>

	* fixinc/inclhack.def (solaris_mutex_init_1): New; Fix
	buggy Solaris mutex/cond initializers.
	(solaris_mutex_init): Rename to solaris_mutex_init_2.
	* fixinc/fixincl.x: Regenerate.
	* fixinc/tests/base/pthread.h: Update.

and these entries on mainline:

2003-03-28  Albert Chin-A-Young  <china@thewrittenword.com>

	* gcc/fixinc/inclhack.def: Update solaris_mutex_init_1 to
	work on Solaris 2.5.1.

2003-03-22  DJ Delorie  <dj at redhat dot com>,
	Bruce Korb  <bkorb at gnu dot org>

	* fixinc/inclhack.def (solaris_mutex_init_1): New; Fix
	buggy Solaris 2.6 mutex/cond initializers.
	(solaris_mutex_init): Rename to solaris_mutex_init_2.
	* fixinc/fixincl.x: Regenerate.
	* fixinc/tests/base/pthread.h: Update.
	* fixinc/fixincl.c(initialize): be explicit about the default case
	and indicate verbose level when being very, very verbose.
	* fixinc/check.tpl(VERBOSE): provide a means for passing the value in

but none on the 3.3 branch?

-- 
Eric Botcazou

Re: GCC 3.3

[Eric Botcazou]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

> If there is some incredibly vital patch, it can go in to the next
> prerelease, but things like "glibc really wants this" aren't going to
> make it in that round.

Sorry for arriving so late in the game but, as the machines at stake are not 
exactly fast, I was previously concentrating on the 3.2.3 release and then 
left for two weeks...

The bad news: we have a bunch of C++ regressions on sparc-sun-solaris2.5.1

3.3pre: http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00337.html
3.2.3pre: http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00894.html

and sparc-sun-solaris2.6

3.3pre: http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00338.html
3.2.3pre: http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00894.html

(sparc-sun-solaris2.[7-9] are clean).

The good news: they appear to have the same origin (in libstdc++-v3), see the 
attached log file.

I'm going to try to debug them but, as I'm not an expert of libstdc++-v3 at 
all, any help would be *greatly* appreciated (emphasis by me :-).

-- 
Eric Botcazou

[-- Attachment #2: solaris2.6-c++bug.log --]
[-- Type: text/x-log, Size: 13418 bytes --]

Executing on host: /opt/build/eric/gcc-3_3-branch/gcc/testsuite/../g++ -B/opt/bu
ild/eric/gcc-3_3-branch/gcc/testsuite/../ /opt/build/eric/gcc-3_3-branch/src/gcc
/testsuite/g++.dg/init/array4.C  -nostdinc++ -I/opt/build/eric/gcc-3_3-branch/sp
arc-sun-solaris2.6/libstdc++-v3/include/sparc-sun-solaris2.6 -I/opt/build/eric/g
cc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include -I/opt/build/eric/gcc-3_
3-branch/src/libstdc++-v3/libsupc++ -I/opt/build/eric/gcc-3_3-branch/src/libstdc
++-v3/libio -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/include/backward -
I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/testsuite -fmessage-length=0
-ansi -pedantic-errors -Wno-long-long  -S  -o array4.s    (timeout = 300)
In file included from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/stl_alloc.h:89,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/memory:55,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/string:48,
                 from /opt/build/eric/gcc-3_3-branch/src/gcc/testsuite/g++.dg/in
it/array4.C:8:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In constructor `std::_Refcount_Base::_Refcount_Base(unsigned int)':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:74: error: brace-enclosed initializer used to initialize `uint8_t'
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: At global scope:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In instantiation of `__gthread_mutex_t std::_Swap_lock_struct<0>::_
S_swap_lock':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:122:   instantiated from here
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:115: error: brace-enclosed initializer used to initialize `uint8_t'
compiler exited with status 1


Executing on host: /opt/build/eric/gcc-3_3-branch/gcc/testsuite/../g++ -B/opt/bu
ild/eric/gcc-3_3-branch/gcc/testsuite/../ /opt/build/eric/gcc-3_3-branch/src/gcc
/testsuite/g++.dg/template/friend.C  -nostdinc++ -I/opt/build/eric/gcc-3_3-branc
h/sparc-sun-solaris2.6/libstdc++-v3/include/sparc-sun-solaris2.6 -I/opt/build/er
ic/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include -I/opt/build/eric/gc
c-3_3-branch/src/libstdc++-v3/libsupc++ -I/opt/build/eric/gcc-3_3-branch/src/lib
stdc++-v3/libio -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/include/backwa
rd -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/testsuite -fmessage-length=
0   -ansi -pedantic-errors -Wno-long-long    -L/opt/build/eric/gcc-3_3-branch/sp
arc-sun-solaris2.6//libstdc++-v3/src/.libs -L/opt/build/eric/gcc-3_3-branch/spar
c-sun-solaris2.6//libiberty  -lm   -o friend.exe    (timeout = 300)
In file included from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/stl_alloc.h:89,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/memory:55,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/string:48,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/locale_classes.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/ios_base.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ios:49,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ostream:45,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/iostream:45,
                 from /opt/build/eric/gcc-3_3-branch/src/gcc/testsuite/g++.dg/te
mplate/friend.C:5:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In constructor `std::_Refcount_Base::_Refcount_Base(unsigned int)':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:74: error: brace-enclosed initializer used to initialize `uint8_t'
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: At global scope:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In instantiation of `__gthread_mutex_t std::_Swap_lock_struct<0>::_
S_swap_lock':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:122:   instantiated from here
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:115: error: brace-enclosed initializer used to initialize `uint8_t'
compiler exited with status 1


Executing on host: /opt/build/eric/gcc-3_3-branch/gcc/testsuite/../g++ -B/opt/bu
ild/eric/gcc-3_3-branch/gcc/testsuite/../ /opt/build/eric/gcc-3_3-branch/src/gcc
/testsuite/g++.dg/template/friend10.C  -nostdinc++ -I/opt/build/eric/gcc-3_3-bra
nch/sparc-sun-solaris2.6/libstdc++-v3/include/sparc-sun-solaris2.6 -I/opt/build/
eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include -I/opt/build/eric/
gcc-3_3-branch/src/libstdc++-v3/libsupc++ -I/opt/build/eric/gcc-3_3-branch/src/l
ibstdc++-v3/libio -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/include/back
ward -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/testsuite -fmessage-lengt
h=0   -ansi -pedantic-errors -Wno-long-long    -L/opt/build/eric/gcc-3_3-branch/
sparc-sun-solaris2.6//libstdc++-v3/src/.libs -L/opt/build/eric/gcc-3_3-branch/sp
arc-sun-solaris2.6//libiberty  -lm   -o ./friend10.exe    (timeout = 300)
In file included from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/stl_alloc.h:89,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/memory:55,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/string:48,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/locale_classes.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/ios_base.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ios:49,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ostream:45,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/iostream:45,
                 from /opt/build/eric/gcc-3_3-branch/src/gcc/testsuite/g++.dg/te
mplate/friend10.C:9:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In constructor `std::_Refcount_Base::_Refcount_Base(unsigned int)':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:74: error: brace-enclosed initializer used to initialize `uint8_t'
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: At global scope:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In instantiation of `__gthread_mutex_t std::_Swap_lock_struct<0>::_
S_swap_lock':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:122:   instantiated from here
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:115: error: brace-enclosed initializer used to initialize `uint8_t'
compiler exited with status 1


Executing on host: /opt/build/eric/gcc-3_3-branch/gcc/testsuite/../g++ -B/opt/bu
ild/eric/gcc-3_3-branch/gcc/testsuite/../ /opt/build/eric/gcc-3_3-branch/src/gcc
/testsuite/g++.old-deja/g++.benjamin/15071.C  -nostdinc++ -I/opt/build/eric/gcc-
3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/sparc-sun-solaris2.6 -I/opt
/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include -I/opt/buil
d/eric/gcc-3_3-branch/src/libstdc++-v3/libsupc++ -I/opt/build/eric/gcc-3_3-branc
h/src/libstdc++-v3/libio -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/inclu
de/backward -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/testsuite -fmessag
e-length=0  -ansi -pedantic-errors -Wno-long-long    -L/opt/build/eric/gcc-3_3-b
ranch/sparc-sun-solaris2.6//libstdc++-v3/src/.libs -L/opt/build/eric/gcc-3_3-bra
nch/sparc-sun-solaris2.6//libiberty  -lstdc++ -lm   -o /opt/build/eric/gcc-3_3-b
ranch/gcc/testsuite/g++-benjamin-15071-C.exe    (timeout = 300)
In file included from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/stl_alloc.h:89,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/memory:55,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/string:48,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/locale_classes.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/ios_base.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ios:49,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ostream:45,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/iostream:45,
                 from /opt/build/eric/gcc-3_3-branch/src/gcc/testsuite/g++.old-d
eja/g++.benjamin/15071.C:5:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In constructor `std::_Refcount_Base::_Refcount_Base(unsigned int)':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:74: error: brace-enclosed initializer used to initialize `uint8_t'
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: At global scope:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In instantiation of `__gthread_mutex_t std::_Swap_lock_struct<0>::_
S_swap_lock':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:122:   instantiated from here
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:115: error: brace-enclosed initializer used to initialize `uint8_t'
compiler exited with status 1


Executing on host: /opt/build/eric/gcc-3_3-branch/gcc/testsuite/../g++ -B/opt/bu
ild/eric/gcc-3_3-branch/gcc/testsuite/../ /opt/build/eric/gcc-3_3-branch/src/gcc
/testsuite/g++.old-deja/g++.brendan/copy9.C  -nostdinc++ -I/opt/build/eric/gcc-3
_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/sparc-sun-solaris2.6 -I/opt/
build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include -I/opt/build
/eric/gcc-3_3-branch/src/libstdc++-v3/libsupc++ -I/opt/build/eric/gcc-3_3-branch
/src/libstdc++-v3/libio -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/includ
e/backward -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/testsuite -fmessage
-length=0  -ansi -pedantic-errors -Wno-long-long    -L/opt/build/eric/gcc-3_3-br
anch/sparc-sun-solaris2.6//libstdc++-v3/src/.libs -L/opt/build/eric/gcc-3_3-bran
ch/sparc-sun-solaris2.6//libiberty  -lstdc++ -lm   -o /opt/build/eric/gcc-3_3-br
anch/gcc/testsuite/g++-brendan-copy9-C.exe    (timeout = 300)
In file included from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/stl_alloc.h:89,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/memory:55,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/string:48,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/locale_classes.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/ios_base.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ios:49,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ostream:45,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/iostream:45,
                 from /opt/build/eric/gcc-3_3-branch/src/gcc/testsuite/g++.old-d
eja/g++.brendan/copy9.C:2:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In constructor `std::_Refcount_Base::_Refcount_Base(unsigned int)':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:74: error: brace-enclosed initializer used to initialize `uint8_t'
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: At global scope:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In instantiation of `__gthread_mutex_t std::_Swap_lock_struct<0>::_
S_swap_lock':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:122:   instantiated from here
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:115: error: brace-enclosed initializer used to initialize `uint8_t'
compiler exited with status 1

Re: GCC 3.3

[Mark Mitchell]

On Mon, 2003-05-05 at 11:21, Eric Botcazou wrote:
> > And then, I'm running the prerelease; no ifs, ands, or buts.
> 
> What of "what ofs"? :-)

Nope, not those either. :-)

> > If there is some incredibly vital patch, it can go in to the next
> > prerelease, but things like "glibc really wants this" aren't going to
> > make it in that round.
> 
> What of trivial patches posted three weeks ago:

The problem is that if I do not draw the line, this process will go on
forever.  I am 100% confident that there are at least ten other
"trivial", good, useful patches for issues that someone will care about
lying around out there.  

That's sad -- but I've given plenty of warnings.  

In our current process, it's up to maintainers to review these things in
a timely fashion.

> 	http://gcc.gnu.org/ml/gcc/2003-04/msg00611.html
> 
> with some support from a maintainer:

If this patch is reviewed -- and tested on at least three platforms that
use this Makefile target -- it can go in after the first prerelease.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Eric Botcazou]

> And then, I'm running the prerelease; no ifs, ands, or buts.

What of "what ofs"? :-)

> If there is some incredibly vital patch, it can go in to the next
> prerelease, but things like "glibc really wants this" aren't going to
> make it in that round.

What of trivial patches posted three weeks ago:

	http://gcc.gnu.org/ml/gcc/2003-04/msg00611.html

with some support from a maintainer:

	http://gcc.gnu.org/ml/gcc/2003-04/msg00632.html

and for some reason still unreviewed?

-- 
Eric Botcazou

GCC 3.3

[Mark Mitchell]

I'm going to review Kean's patch to deal with rcs_id, and hopefully
check that in this morning.

I'm going to wait for Richard and David to commit the changes I've
approved there.

And then, I'm running the prerelease; no ifs, ands, or buts.

If there is some incredibly vital patch, it can go in to the next
prerelease, but things like "glibc really wants this" aren't going to
make it in that round.

Thanks,

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: gcc 3.3

[Geoff Keating]

Mark Mitchell <mark@codesourcery.com> writes:

> On Tue, 2003-04-29 at 08:08, Wolfgang Bangerth wrote:
> > Mark,
> > the only thing that comes to my mind is PR 9393 (the name mangling for 
> > anonymous namespace non-variability thing). Geoff applied a patch to 
> > mainline on Apr 12th, but not to 3.3. It's not exactly small, though.
> 
> I think we'll pass on that one, but thanks.

Oh, rats, I forgot to actually commit that patch.  Well, too late now,
but we can put it in for 3.3.1.

The patch is pretty localised, but it changes configury which is
probably inappropriate at this point.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: gcc 3.3

[Mark Mitchell]

On Tue, 2003-04-29 at 08:08, Wolfgang Bangerth wrote:
> Mark,
> the only thing that comes to my mind is PR 9393 (the name mangling for 
> anonymous namespace non-variability thing). Geoff applied a patch to 
> mainline on Apr 12th, but not to 3.3. It's not exactly small, though.

I think we'll pass on that one, but thanks.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-04-29 at 12:18, Ulrich Weigand wrote:
> 
> Jan Hubicka wrote:
> 
> >I commit the attached patch.  Urlich does this solve the problems you
> >are seeing?
> 
> Yes.  (This is exactly how I was solving the problem locally while
> waiting for a proper fix, so I don't need to test it again ;-))

Great; I've now marked this as a 3.4, but not 3.3, PR.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Ulrich Weigand]

Jan Hubicka wrote:

>I commit the attached patch.  Urlich does this solve the problems you
>are seeing?

Yes.  (This is exactly how I was solving the problem locally while
waiting for a proper fix, so I don't need to test it again ;-))


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com

Re: GCC 3.3

[Jan Hubicka]

> On Tue, 2003-04-29 at 12:00, Jan Hubicka wrote:
> > > I don't understand your new patch:
> > > 
> > > ! 	  /* Do not delete instructions initializing operands needed by dead
> > > ! 	     instruction with side effects.  */
> > > ! 	  || (!counts[REGNO (x)] && incr > 0
> > > ! 	      && insn_live_p (insn, NULL)))
> > >  
> > > First, INSN is live -- not dead, given that insn_live_p holds.
> > 
> > It is not live, just it is undeletable because it has side effects or
> > something else.  insn_live_p checks that.
> 
> The bottom line is that I think this new code needs considerably more
> explanation; something like:
> 
> /* If the instruction is live -- or if it has side effects that must  be
> preserved -- and ..., then we update COUNTS, even if the register in use
> is the destination register because ... */
> 
> That last part is still in conflict with the heading for the function,
> which says "Don't count a usage of DEST," so that needs to be changed as
> well.

Yes, the original code was in conflict as well, so I didn't noticed that
when doing the patch.
> 
> If checking counts[REGNO(x)] is an optimization, then the actual count
> doesn't seem to matter much; it's just whether or not it's zero. 
> (Because you're only going to adding INCR sometimes.)  If that's true,
> then the whole function ought to be changed so that rather than adding
> incr, you're just setting a flag.

On the deeper tought this is probably wrong - some other instruction
that did use the counter may get removed but we still should not remove
the induction variable.
> 
> > OK.  My CVS access is deadly slow here in Barcelona, but I will try to
> > do it tonight.
> 
> If you cannot, please let me know so that I can do it.

Somehow the net is in good shape today.

I will prepare updated patch...

Honza
> 
> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com

Re: GCC 3.3

[Jan Hubicka]

> In light of this, please revert your original patch on the 3.3 branch,
> but proceed with fixing it on the mainline.  We can consider this
> optimization for 3.3.1 if it is stable by then.
I commit the attached patch.  Urlich does this solve the problems you
are seeing?

Index: ChangeLog
===================================================================
RCS file: /cvs/gcc/gcc/gcc/ChangeLog,v
retrieving revision 1.16114.2.493
diff -c -3 -p -r1.16114.2.493 ChangeLog
*** ChangeLog	29 Apr 2003 18:46:56 -0000	1.16114.2.493
--- ChangeLog	29 Apr 2003 19:07:42 -0000
***************
*** 1,3 ****
--- 1,7 ----
+ Tue Apr 29 21:07:00 CEST 2003  Jan Hubicka  <jh@suse.cz>
+ 
+ 	* cse.c (count_reg_usage): Revert my previous patch.
+ 	
  2003-04-29  Zack Weinberg  <zack@codesourcery.com>
  
  	* config.gcc: Install obsolete target list for GCC 3.3.
Index: cse.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cse.c,v
retrieving revision 1.244.2.1
diff -c -3 -p -r1.244.2.1 cse.c
*** cse.c	1 Apr 2003 19:17:10 -0000	1.244.2.1
--- cse.c	29 Apr 2003 19:07:43 -0000
*************** count_reg_usage (x, counts, dest, incr)
*** 7528,7535 ****
        /* Unless we are setting a REG, count everything in SET_DEST.  */
        if (GET_CODE (SET_DEST (x)) != REG)
  	count_reg_usage (SET_DEST (x), counts, NULL_RTX, incr);
        count_reg_usage (SET_SRC (x), counts,
! 		       SET_DEST (x),
  		       incr);
        return;
  
--- 7528,7542 ----
        /* Unless we are setting a REG, count everything in SET_DEST.  */
        if (GET_CODE (SET_DEST (x)) != REG)
  	count_reg_usage (SET_DEST (x), counts, NULL_RTX, incr);
+ 
+       /* If SRC has side-effects, then we can't delete this insn, so the
+ 	 usage of SET_DEST inside SRC counts.
+ 
+ 	 ??? Strictly-speaking, we might be preserving this insn
+ 	 because some other SET has side-effects, but that's hard
+ 	 to do and can't happen now.  */
        count_reg_usage (SET_SRC (x), counts,
! 		       side_effects_p (SET_SRC (x)) ? NULL_RTX : SET_DEST (x),
  		       incr);
        return;
  

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-04-29 at 12:00, Jan Hubicka wrote:
> > I don't understand your new patch:
> > 
> > ! 	  /* Do not delete instructions initializing operands needed by dead
> > ! 	     instruction with side effects.  */
> > ! 	  || (!counts[REGNO (x)] && incr > 0
> > ! 	      && insn_live_p (insn, NULL)))
> >  
> > First, INSN is live -- not dead, given that insn_live_p holds.
> 
> It is not live, just it is undeletable because it has side effects or
> something else.  insn_live_p checks that.

The bottom line is that I think this new code needs considerably more
explanation; something like:

/* If the instruction is live -- or if it has side effects that must  be
preserved -- and ..., then we update COUNTS, even if the register in use
is the destination register because ... */

That last part is still in conflict with the heading for the function,
which says "Don't count a usage of DEST," so that needs to be changed as
well.

If checking counts[REGNO(x)] is an optimization, then the actual count
doesn't seem to matter much; it's just whether or not it's zero. 
(Because you're only going to adding INCR sometimes.)  If that's true,
then the whole function ought to be changed so that rather than adding
incr, you're just setting a flag.

> OK.  My CVS access is deadly slow here in Barcelona, but I will try to
> do it tonight.

If you cannot, please let me know so that I can do it.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Jan Hubicka]

> I don't understand your new patch:
> 
> ! 	  /* Do not delete instructions initializing operands needed by dead
> ! 	     instruction with side effects.  */
> ! 	  || (!counts[REGNO (x)] && incr > 0
> ! 	      && insn_live_p (insn, NULL)))
>  
> First, INSN is live -- not dead, given that insn_live_p holds.

It is not live, just it is undeletable because it has side effects or
something else.  insn_live_p checks that.
> 
> Second, no deletion is taking place here.

Yes, but we have to increase the counter in order to avoid other
deletions to happen (all values used by this insn must appear live.  All
the test does it to bypass values both used and initialized by the insn
so the insn is deleted entirely in the case the values are not elsewhere
like in dead induction variable)
>   
> Third, checking incr > 0 is pointless, since all that happens if the
> condition is true is:
> 
>   counts[REGNO (x)] += incr;

incr is either 1 or -1.
> 
> Fourth, why check !counts[REGNO (x)]?
This is just optimization - we don't have to call that expensive
function when the instruction is live for another reason already.
> 
> I think you want something more like:
> 
>   /* If this instruction is live, then even modifications to the  
> destination register matter. */
>   || insn_live_p (insn, NULL)

No, modifications never matters, just uses.
> 
> But then, the comment above the entire function needs to change, since
> it explicitly says that modifications to the destination register don't
> matter.
> 
> In light of this, please revert your original patch on the 3.3 branch,
> but proceed with fixing it on the mainline.  We can consider this
> optimization for 3.3.1 if it is stable by then.

OK.  My CVS access is deadly slow here in Barcelona, but I will try to
do it tonight.

Honza
> 
> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-04-29 at 07:02, Jan Hubicka wrote:
> > Mark Mitchell wrote:
> > 
> > >If you know of a regression for which you think we should hold the
> > >release:
> > 
> > There is a serious regression on s390 (Linux kernel silently
> > miscompiled).  See optimization/10536.
> > 
> > This is a regression over 3.2, introduced by this patch:
> > http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01070.html
> > 
> > It can be fixed either by reverting that patch, or else by this fix:
> > http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01318.html
> > (which has not yet been approved).
> 
> Mark,
> reverting of the patch is safe as the patch is purely compilation time
> optimization.  I also tested the proposer proper fix relatively
> troroughly in SuSE's internal compiler and it appears to cause no
> problems as well. 

I don't understand your new patch:

! 	  /* Do not delete instructions initializing operands needed by dead
! 	     instruction with side effects.  */
! 	  || (!counts[REGNO (x)] && incr > 0
! 	      && insn_live_p (insn, NULL)))
 
First, INSN is live -- not dead, given that insn_live_p holds.

Second, no deletion is taking place here.
  
Third, checking incr > 0 is pointless, since all that happens if the
condition is true is:

  counts[REGNO (x)] += incr;

Fourth, why check !counts[REGNO (x)]?

I think you want something more like:

  /* If this instruction is live, then even modifications to the  
destination register matter. */
  || insn_live_p (insn, NULL)

But then, the comment above the entire function needs to change, since
it explicitly says that modifications to the destination register don't
matter.

In light of this, please revert your original patch on the 3.3 branch,
but proceed with fixing it on the mainline.  We can consider this
optimization for 3.3.1 if it is stable by then.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-04-29 at 10:06, Benjamin Kosnik wrote:
> 
> >This isn't marked as a 3.3 regression; please update it's synopsis so
> >that I can see it.  Otherwise, I will forget.
> 
> Done.

Thanks.

Yes, I agree that this is critical; please do keep me apprised of
progress.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Benjamin Kosnik]

>This isn't marked as a 3.3 regression; please update it's synopsis so
>that I can see it.  Otherwise, I will forget.

Done.

>If this only happens to be people using GCC in non-default locales, it's
>not the end of the world.  The ABI issues are more important than the
>memory leaks.

No. It's all streams including the standard "C" objects like cout, in
addition to the ABI issues.

-benjamin

Re: GCC 3.3

[Christopher Faylor]

On Tue, Apr 29, 2003 at 09:34:13AM -0700, Mark Mitchell wrote:
>> You submitted a patch for this and later reverted it. Maybe is it possible
>> to come up with a proper patch before 3.3 is released?
>
>I'm not planning to volunteer my time to work on this particular bug.
>
>(Yes, all the nuances in that sentence are intentional.)
>
>It would be great if this bug were fixed, so I've copied Christopher
>Faylor (the Windows port maintainer) on this email.
>
>Christopher, would you take a look at PR 7910 ASAP?

I'll look at it but it won't be ASAP.  I'd choose to volunteer my time
but my time is not volunteerable for the extended period that would
be required for this bug.

cgf

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-04-29 at 09:09, Benjamin Kosnik wrote:
> 
> libstdc++/10276
> 
> There are various unresolved issues with the named locale caching,
> including memory leaks, and potential ABI issues. I thought I'd have
> more time to work on this, but I guess four days is better than four hours.

This isn't marked as a 3.3 regression; please update it's synopsis so
that I can see it.  Otherwise, I will forget.

If this only happens to be people using GCC in non-default locales, it's
not the end of the world.  The ABI issues are more important than the
memory leaks.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Mark Mitchell]

> You submitted a patch for this and later reverted it. Maybe is it possible
> to come up with a proper patch before 3.3 is released?

I'm not planning to volunteer my time to work on this particular bug.

(Yes, all the nuances in that sentence are intentional.)

It would be great if this bug were fixed, so I've copied Christopher
Faylor (the Windows port maintainer) on this email.

Christopher, would you take a look at PR 7910 ASAP?

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Benjamin Kosnik]

libstdc++/10276

There are various unresolved issues with the named locale caching,
including memory leaks, and potential ABI issues. I thought I'd have
more time to work on this, but I guess four days is better than four hours.

I'm now on this 100%, and will give you status daily.

-benjamin

Re: GCC 3.3

[Giovanni Bajo]

Hi Mark,

for us windows users, there is an important regression in winnt.c, see
pr/7910. This has been broken for many months now, it has been reported in
at least 6 different PRs, from different people and in different (and always
legal) code. I guess that it's breaking a lot of windows-specific code out
there.

You submitted a patch for this and later reverted it. Maybe is it possible
to come up with a proper patch before 3.3 is released?

Giovanni Bajo

Re: gcc 3.3

[Wolfgang Bangerth]

Mark,
the only thing that comes to my mind is PR 9393 (the name mangling for 
anonymous namespace non-variability thing). Geoff applied a patch to 
mainline on Apr 12th, but not to 3.3. It's not exactly small, though.

I don't feel very strongly about it, having discovered yesterday that icc 
has the same bug. So we have to work around that anyway in our code :-)

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: GCC 3.3

[Jan Hubicka]

> Mark Mitchell wrote:
> 
> >If you know of a regression for which you think we should hold the
> >release:
> 
> There is a serious regression on s390 (Linux kernel silently
> miscompiled).  See optimization/10536.
> 
> This is a regression over 3.2, introduced by this patch:
> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01070.html
> 
> It can be fixed either by reverting that patch, or else by this fix:
> http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01318.html
> (which has not yet been approved).

Mark,
reverting of the patch is safe as the patch is purely compilation time
optimization.  I also tested the proposer proper fix relatively
troroughly in SuSE's internal compiler and it appears to cause no
problems as well. 

Honza

Re: GCC 3.3

[Ulrich Weigand]

Mark Mitchell wrote:

>If you know of a regression for which you think we should hold the
>release:

There is a serious regression on s390 (Linux kernel silently
miscompiled).  See optimization/10536.

This is a regression over 3.2, introduced by this patch:
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01070.html

It can be fixed either by reverting that patch, or else by this fix:
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01318.html
(which has not yet been approved).


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com

Re: GCC 3.3

[Mike Stump]

On Tuesday, March 11, 2003, at 07:36 PM, Mark Mitchell wrote:
>> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00591.html
>>
>> These patches solve a compile time performance regression that was
>> introduced when contexting for GC went it and was used.
>
> OK, go ahead and check these in, mainline and branch.

Done.  Thanks.  If anyone trips over prefetch not working, let us know. 
  I think this would be the first time it's been used in the compiler.  
I turned off that part of the patch for 3.3 to avoid any potential 
problems.

Re: GCC 3.3

[Olivier Hainque]

Hello again,

Just a small clarification:

> Ada fails to build under hpux 10.20 on 3.3 because the 3.2 version
> of libgnat uses a call to a system routine that's not available under
> 10.X.

 Right.

> The routine is part of the hpux 11.X unwind library and it's
> used for exception support.

 The routine is actually not used for exception support per se, but only for
 the computation of call-chain backtraces.

 It turns out that it is most often used together with exceptions, to attach
 to exception occurrences a traceback describing the call-chain at the point
 of the raise. 

 This is optional, however, and missing this feature does not prevent the base
 exception support to work.





 

Re: GCC 3.3

[Olivier Hainque]

John David Anglin wrote:
> There's also ada/9953
[...]
> I believe the ACT people are working on this PR and I am hopeful that
> there will be a fix.

 Indeed. A patch will be submitted shortly.

 Olivier

Re: GCC 3.3

[John David Anglin]

Hi Mark,

PR 10024 wasn't on your list.  It is marked as a 3.3 regression.

There's also ada/9953.  It's not marked high or as a 3.3 regression.
Ada fails to build under hpux 10.20 on 3.3 because the 3.2 version
of libgnat uses a call to a system routine that's not available under
10.X.  The routine is part of the hpux 11.X unwind library and it's
used for exception support.  I am not sure whether this PR should
be high priority.  The main reason on my part to fix the build under
hpux 10.20 is that it is quite challenging to do the initial
bootstrap under hpux.  It involves starting from a version of gcc 2.8.1
which is rather broken.  I may be able to bootstrap ada under hpux 11
by bring the key tools over from hpux 10 but I haven't tried it.  I
believe the ACT people are working on this PR and I am hopeful that
there will be a fix.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: GCC 3.3

[Janis Johnson]

On Tue, Mar 11, 2003 at 01:30:58PM -0800, Mark Mitchell wrote:
> 
> We have about 50 open high-priority PRs representing regressions
> against GCC 3.3.

I've changed the synopsis of optimization/6597 to show that it is a
regression in 3.3 and 3.4, but I didn't bump the priority.  This is an
ICE that shows up only with checking enabled, and I've only been able
to reproduce it on ia64-linux.  I'll let Mark decide whether it should
have a higher priority.  I verified last week that it still exists.

Janis

Re: GCC 3.3

[Mark Mitchell]

On Wed, 2003-03-12 at 09:58, Joe Buck wrote:
> On Wed, Mar 12, 2003 at 11:25:17AM +0000, Richard Earnshaw wrote:
> > > > ???> Go to Query, then look for high priority PRs that have "3.3" in the
> > > > synopsis.  How much easier can it be?  Thanks to (mostly) Wolfgang,
> > > > hi-pri PRs are now classified better than ever before!
> > > 
> > > Amazingly, I did not think of that.
> > > 
> > 
> > Unfortunately, that misses out a few that are marked as regressions, but 
> > aren't at high priority.  These are (if I've typed them in correctly):
> > 
> > Medium: 10024 9972 9848 9772 9594 9469 9311 8963 8960 7675 6162
> > Low: 9163 5975
> > 
> > In addition there are several PRs which refer to 3.3 but are not marked as 
> > regressions.
> 
> The right thing to do is to mark these as high priority and to put
> the standard prefix in the Synopsis line. 

Note further that at least a few of those may have been given less than
high priority on purpose; I've downgraded a couple of PRs.  When I do
that, there's always a note in the PR record.

Thanks for helping out with this!

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Joe Buck]

On Wed, Mar 12, 2003 at 11:25:17AM +0000, Richard Earnshaw wrote:
> > > ???> Go to Query, then look for high priority PRs that have "3.3" in the
> > > synopsis.  How much easier can it be?  Thanks to (mostly) Wolfgang,
> > > hi-pri PRs are now classified better than ever before!
> > 
> > Amazingly, I did not think of that.
> > 
> 
> Unfortunately, that misses out a few that are marked as regressions, but 
> aren't at high priority.  These are (if I've typed them in correctly):
> 
> Medium: 10024 9972 9848 9772 9594 9469 9311 8963 8960 7675 6162
> Low: 9163 5975
> 
> In addition there are several PRs which refer to 3.3 but are not marked as 
> regressions.

The right thing to do is to mark these as high priority and to put
the standard prefix in the Synopsis line.  I'll make a pass at this if
no one else has, but I'd want to confirm that these are still issues,
and, thanks to continued problems with subversions.gcc.org, I can't
update from CVS ("waiting for anoncvs's lock in /cvsroot/gcc/gcc" forever).

Re: GCC 3.3

[law]

In message <1047430325.30643.154.camel@steven>, Steven Bosscher writes:
 >PR optimization/9357
 >This is an -fssa issue, and rtl-ssa is not officially supported (i.e. it
 >is known not.to work correctly in all cases).  Maybe this one should
 >just be suspended then?
That sounds like a wise idea to me.

jeff

Re: GCC 3.3

[Eric Botcazou]

> Medium: 10024 9972 9848 9772 9594 9469 9311 8963 8960 7675 6162

The correct fix for PR opt/7675 would not be 3.3 material I think and the bug 
is really a corner case.

-- 
Eric Botcazou

Re: GCC 3.3

[Richard Earnshaw]

> > ???> Go to Query, then look for high priority PRs that have "3.3" in the
> > synopsis.  How much easier can it be?  Thanks to (mostly) Wolfgang,
> > hi-pri PRs are now classified better than ever before!
> 
> Amazingly, I did not think of that.
> 

Unfortunately, that misses out a few that are marked as regressions, but 
aren't at high priority.  These are (if I've typed them in correctly):

Medium: 10024 9972 9848 9772 9594 9469 9311 8963 8960 7675 6162
Low: 9163 5975

In addition there are several PRs which refer to 3.3 but are not marked as 
regressions.

R.

Re: GCC 3.3

[Mark Mitchell]

> ???> Go to Query, then look for high priority PRs that have "3.3" in the
> synopsis.  How much easier can it be?  Thanks to (mostly) Wolfgang,
> hi-pri PRs are now classified better than ever before!

Amazingly, I did not think of that.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-03-11 at 16:04, Mike Stump wrote:
> On Tuesday, March 11, 2003, at 01:30 PM, Mark Mitchell wrote:
> > At this point, I'm going to change the rules for the 3.3 branch
> > slightly.  In particular, compile-time improvement patches need to get
> > normal approval from a maintainer *and* a review by me.
> 
> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00591.html
> 
> These patches solve a compile time performance regression that was 
> introduced when contexting for GC went it and was used. 

OK, go ahead and check these in, mainline and branch.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Steven Bosscher]

Hi Mark,

If you've not already looked into all high-priority 3.3 PRs, here's a
reference to four patches.  Also one patch seens to be fixed, and one
should maybe suspended...


On Tue 11-03-2003  22:30  Mark Mitchell wrote:
> 9928	[3.3/3.4 regression] ICE on duplicate enum declaration
> 	ebotcazou

PR c/9928
(Patch: http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00972.html)
OK'ed by rth but not commited yet)


> 9357	[3.2/3.3/3.4 regression] SegFault with -fssa -funroll-loops -fprofile-arcs

PR optimization/9357
This is an -fssa issue, and rtl-ssa is not officially supported (i.e. it
is known not.to work correctly in all cases).  Maybe this one should
just be suspended then?


> 8634	[3.2/3.3 regression] incorrect code for inlining of memcpy under -O2

PR optimization/8634
(Patch: http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00533.html)
Never reviewed.


> 7189	[3.2/3.3 regression] gcc -O2 -Wall does not print ``control reaches end of non-void function'' warning
> 	steven

PR optimization/7189
(Patch: http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00086.html)
This one is on the mainline already.


6942  [3.3 regression] Error detected at g-spipat.adb:4828:7 (cygwin)
(Was not in your list)

PR middle-end/6942
This problem is not present in trunk at Wed Mar 5 2003, keep an eye on
it (maybe put it in feedback).


> 6440	[3.2/3.3 regression] ice in template friend member function
> 	mmitchel

PR c++/6440
(Patch: http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00423.html)
The PR is assigned to you but the patch is from Kriang Lerdsuwanakij. 
It also still needs to be reviewed (it's a week old now).


Greetz
Steven

Re: GCC 3.3

[Janis Johnson]

On Tue, Mar 11, 2003 at 01:30:58PM -0800, Mark Mitchell wrote:
> 
> We have about 50 open high-priority PRs representing regressions
> against GCC 3.3.
> 
> Please look through this list and see if you can't knock a few of
> these out.

For anyone fixing these: let me know if you'd like me to identify the
patch that introduced the regression or, if applicable, the one that
fixed in in mainline, assuming it can be reproduced on i686-linux-gnu,
ia64-linux-gnu, powerpc-linux-gnu, or powerpc64-linux-gnu.  Keep in
mind that this isn't usually useful for old C++ regressions, and in
many other cases the patch turns out to be too extensive to be useful.
Sometimes it helps.

Janis

Re: GCC 3.3

[Mike Stump]

On Tuesday, March 11, 2003, at 01:30 PM, Mark Mitchell wrote:
> At this point, I'm going to change the rules for the 3.3 branch
> slightly.  In particular, compile-time improvement patches need to get
> normal approval from a maintainer *and* a review by me.

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00591.html

These patches solve a compile time performance regression that was 
introduced when contexting for GC went it and was used.  For my 
testcase it was a 31.3% speedup.  You previously OKed the work in:

http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02457.html

but Geoff wanted a few issues addressed, so I addressed them, but I 
never heard back from him, he's been busy.

The original patch, if you want to see the complete history, started 
with:

http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02451.html

Re: GCC 3.3

[Steven Bosscher]

Op di 11-03-2003, om 22:30 schreef Mark Mitchell:
> 
> We have about 50 open high-priority PRs representing regressions
> against GCC 3.3.
> 
> I've heard a few people say that "all the open PRs are C++ PRs" -- but
> that's clearly false, looking at the list below.  It's true that we
> C++ folks have our work cut out for us, but there are plenty of back
> end and optimizer issues in the list below.

There used to be more C++ PRs, but the "C++ folks" have fixed so many
that it doesn't look so bad anymore.  Thanks!

> Gaby, you would make my life a little simpler if you'd take some of
> the high-priority bugs that are only 3.2 regressions and close them,
> after applying patches to the 3.2 branch if you want to do that.
> There are now a lot of 3.2-only PRs open, and it's hard to see what's
> a 3.3 PR and what's a 3.2 PR in GNATS.  This is GNATS' fault...

???
Go to Query, then look for high priority PRs that have "3.3" in the
synopsis.  How much easier can it be?  Thanks to (mostly) Wolfgang,
hi-pri PRs are now classified better than ever before!

That query gives me 58 PRs now; of these I know of three that look like
they're actually fixed or they have a patch pending.  9745 shows up in
this query.  Two weeks ago, there were 78 high priority PRs for 3.3, so
things are looking much better :-)

Greetz
Steven

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-03-11 at 13:44, David Edelsohn wrote:
> 	PR 9091 was fixed in December, but was not closed.  I just closed
> it. 

Thanks.

> 	PR 9745 was not on your list, but is a high priority PR for GCC
> 3.3.

In that case, please mark it as a [3.3 regression] in GNATS.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Geert Bosch]

On Tuesday, Mar 11, 2003, at 16:30 America/New_York, Mark Mitchell 
wrote:

>
> We have about 50 open high-priority PRs representing regressions
> against GCC 3.3.
>
> I've heard a few people say that "all the open PRs are C++ PRs" -- but
> that's clearly false, looking at the list below.  It's true that we
> C++ folks have our work cut out for us, but there are plenty of back
> end and optimizer issues in the list below.
>
...
>
> 9091	[3.3 branch regression] Ada bootstrap failure on powerpc-linux
>

This one has been fixed for a while (thanks David):
> State-Changed-From-To: analyzed->closed
> State-Changed-By: dje
> State-Changed-When: Tue Mar 11 21:36:00 2003
> State-Changed-Why:
>     Fixed with patch to define WIDEST_HARDWARE_FP_SIZE
>     on 2002-12-31

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-03-11 at 13:32, Gabriel Dos Reis wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
> | Gaby, you would make my life a little simpler if you'd take some of
> | the high-priority bugs that are only 3.2 regressions and close them,
> | after applying patches to the 3.2 branch if you want to do that.
> | There are now a lot of 3.2-only PRs open, and it's hard to see what's
> | a 3.3 PR and what's a 3.2 PR in GNATS.  This is GNATS' fault...
> 
> Will take them.

Thanks.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Gaby, you would make my life a little simpler if you'd take some of
| the high-priority bugs that are only 3.2 regressions and close them,
| after applying patches to the 3.2 branch if you want to do that.
| There are now a lot of 3.2-only PRs open, and it's hard to see what's
| a 3.3 PR and what's a 3.2 PR in GNATS.  This is GNATS' fault...

Will take them.

-- Gaby

Re: GCC 3.3

[David Edelsohn]

	PR 9091 was fixed in December, but was not closed.  I just closed
it. 

	PR 9745 was not on your list, but is a high priority PR for GCC
3.3.  I sent a strawman patch earlier this month, but received no
feedback.  The problem ultimately comes down to a nasty aliasing problem
because the PowerPC frame pointer is not a fixed register.

David

GCC 3.3

[Mark Mitchell]

We have about 50 open high-priority PRs representing regressions
against GCC 3.3.

I've heard a few people say that "all the open PRs are C++ PRs" -- but
that's clearly false, looking at the list below.  It's true that we
C++ folks have our work cut out for us, but there are plenty of back
end and optimizer issues in the list below.

At this point, I'm going to change the rules for the 3.3 branch
slightly.  In particular, compile-time improvement patches need to get
normal approval from a maintainer *and* a review by me.  I'm going to
be leery of anything that doesn't look obviously simple and correct to
me.  We've made a lot of good improvements in this regard, and there
are a few more patches I think we can get in, but it's time to focus
on the out-and-out crashes and bad code generation problems.

Please look through this list and see if you can't knock a few of
these out.

I think we are getting pretty close; some of these PRs are duplicates,
and some can get downgraded if we can't fix 'em readily.

Gaby, you would make my life a little simpler if you'd take some of
the high-priority bugs that are only 3.2 regressions and close them,
after applying patches to the 3.2 branch if you want to do that.
There are now a lot of 3.2-only PRs open, and it's hard to see what's
a 3.3 PR and what's a 3.2 PR in GNATS.  This is GNATS' fault...

Thanks,

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

=============================================================================================

10031	3.3/mainline c++ regression

10021	[3.2/3.3/3.4 regression] alias problem during loop pass on m68k

10017	[3.2/3.3/3.4 regression] ICE: unable to find a register to spill in class `GENERAL_REGS'

9936	[3.2/3.3 regression] ICE with local function and variable-length 2d array

9929	[3.3/3.4 regression] Can't find spill register

9928	[3.3/3.4 regression] ICE on duplicate enum declaration
	ebotcazou

9924	[3.2/3.3/3.4 regression] Multiple using statements for builtin functions not allowed

9886	[3.3/3.4 regression][IA64] ICE in final_scan_insn

9865	[3.2/3.3/3.4 regression] Template matching for reference types
	nathan

9853	[3.2/3.3/3.4 regression] miscompilation of non-constant structure initializer

9820	[3.3/3.4 regression] ice in build_baselink (templates)
	jason

9812	[3.2/3.3 regression] ICE in extract_insn, at recog.c:2148

9786	[3.2/3.3/3.4 regression] Ice in fixup_abnormal_edges with -fnon-call-exceptions -O2

9769	[3.2/3.3 regression] miscompilation with -freg-struct-return

9763	[<3.2,3.3,3.4> regression][sparc] Internal compiler error in emit-rtl.c (gen_reg_rxt)

9630	[3.2/3.3/3.4 regression] crash with -freg-struct-return in C++ code

9629	[3.2/3.3/3.4 regression] virtual inheritance segfault

9570	[3.3/3.4 regression] Assember error with -finline-functions with g++-3.3

9474	[3.2/3.3/3.4 regression] GCC freezes in compiling a weird code mixing <iostream> and <iostream.h>

9420	[3.2/3.3/3.4 regression] incomplete type incorrectly reported
	nathan

9357	[3.2/3.3/3.4 regression] SegFault with -fssa -funroll-loops -fprofile-arcs

9315	[3.2/3.3/3.4 regression] problems with overload resolution

9181	[3.2.1/3.3/3.4 regression] ICE with inline assembly in instantiate_virtual_regs_1, at function.c:3974

9123	[3.2/3.3/3.4 regression ] Internal compiler error in do_SUBST at combine.c:434

9091	[3.3 branch regression] Ada bootstrap failure on powerpc-linux

9016	[3.2/3.3/3.4 regression] Failure to consistently constant fold "constant" C++ objects

8964	[3.3/3.4 regression] [ABI] different mangling of names

8962	[3.3 regression] [CygWin] "-O2 -mmmx" makes gcc seg fault

8913	[3.3 regression] ICE in simplify_gen_subreg, at simplify-rtx.c

8866	[3.3/3.4 regression] Bug in switch statement code generation -- missing label

8808	[3.2/3.3 regression] Internal compiler error in extract_constrain_insn_cached

8805	[3.2/3.3/3.4 regression] compile time regression with many member variables

8803	[3.2/3.3/3.4 regression] Internal compiler error in instantiate_virtual_regs_1, at function.c:3974
8730	[3.2/3.3/3.4 regression] Cannot compile C function inside other C function

8634	[3.2/3.3 regression] incorrect code for inlining of memcpy under -O2

8457	[3.2/3.3 regression] ICE in generate_bytecode_insns, at java/jcf-write.c:1850
	aph

8396	[3.2/3.3/3.4 regression] [sparc] optimizer ICE

8361	[3.3/3.4 regression] C++ compile-time performance regression

8306	[3.2/3.3 regression] ICE for bitfield7_y.C in C++ compatibility tests

8300	[3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662

7916	[3.2/3.3/3.4 regression] ICE in instantiate_virtual_register_1

7817	[3.2/3.3 regression] Link to gcc man page in g++ man page incorrect

7257	[3.2/3.3/3.4 regression] -O3 -fverbose-asm does not display -flag-inline-functions
	ebotcazou

7189	[3.2/3.3 regression] gcc -O2 -Wall does not print ``control reaches end of non-void function'' warning
	steven

7086	[3.3/3.4 regression] compile time regression

7050	[3.2/3.3/3.4 regression] g++ segfaults on: (i ? get_string() : throw)
	jason

6871	[3.3/3.4 regression] const objects shouldn't be moved to .bss

6860	[3.2/3.3/3.4 regression] [arm-thumb] pre_insert_copy_insn

6798	[3.2/3.3/3.4 regression] very long compile time with large case-statement

6440	[3.2/3.3 regression] ice in template friend member function
	mmitchel

6387	[3.2/3.3 regression] -fpic -gdwarf-2 -g1 combination give ICE in dwarf2out

6262	[3.2/3.3/3.4 regression] gcc reports internal compiler error on legal code

2001	[3.2/3.3 regression] Inordinately long compile times in reload CSE regs

Re: gcc 3.3

[Nathan Sidwell]

Mark Mitchell wrote:

> > PR 7442 submitted today reports more C++ ABI issues.  This one covers
> > problems with the cxxabi.h file.
> 
> This is a library ABI issue, but not a compiler ABI issue.  (Just so that
> everyone understands that.)  And, it's not even clear to me that the ABI
> committee meant the names of those fields to be normative.  On the other
No I don't think we meant them to be so. And it is certainly permissible
for an implementation to use different (virtual) member functions to
implement the catch & dynamic cast machinery. So (a) the vtables
must only be emitted by the compiler building the runtime, and (b)
a user cannot derived from those classes.


nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: gcc 3.3

[Mark Mitchell]

--On Tuesday, July 30, 2002 07:16:55 PM -0400 Jim Wilson 
<wilson@redhat.com> wrote:

>> The hope is that yes, C++ compiled with gcc 3.3 will be binary compatible
>> with 3.2.  However, there's no guarantees; if gcc 3.2 turns out to have
>> ABI bugs, like 3.1 did, then they will need to be fixed.  The hope is
>> that all the ABI bugs have now been caught, but no-one knows for sure.
>
> PR 7442 submitted today reports more C++ ABI issues.  This one covers
> problems with the cxxabi.h file.

This is a library ABI issue, but not a compiler ABI issue.  (Just so that
everyone understands that.)  And, it's not even clear to me that the ABI
committee meant the names of those fields to be normative.  On the other
hand, we may as well make 'em match.

> I think we will continue to find C++ ABI bugs for a while.  There hasn't
> been any attempt to verify the implementation against the specification.

I keep dropping hints that something might happen here...

I agree with the thrust of your point, though.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: gcc 3.3

[Phil Edwards]

On Wed, Jul 31, 2002 at 09:39:08AM -0700, Joe Buck wrote:
> The intent is for 3.3 to be binary-compatible with 3.2 for C++ code.  As
> for libstdc++, the story might be different depending on whether your
> platform supports symbol versioning,

and uses a recent GNU linker (others could be supported, but nobody has
contributed such support at present),

> which is the approach being used to
> allow for development while keeping things binary-compatible.  Perhaps
> the libstdc++ developers can say more on that one.

We also have an open question about the details of symbol versioning:

    http://gcc.gnu.org/ml/libstdc++/2002-07/msg00177.html


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: gcc 3.3

[Joe Buck]

> I didn't see this addressed on the site...will 3.3 be binary compatible 
> with 3.2 (unlike 3.2>3.1)?

The 3.2/3.1 binary compatibilities affect only C++ code.

The intent is for 3.3 to be binary-compatible with 3.2 for C++ code.  As
for libstdc++, the story might be different depending on whether your
platform supports symbol versioning, which is the approach being used to
allow for development while keeping things binary-compatible.  Perhaps
the libstdc++ developers can say more on that one.

Of course there are no warranties for any of this.

Re: gcc 3.3

[H. J. Lu]

On Wed, Jul 31, 2002 at 12:28:57PM +1000, Fergus Henderson wrote:
> > 
> > Why will the new libfoo.so break bar if it is binary compatible with
> > the old libfoo.so?
> 
> It's not guaranteed to be binary compatible with the old libfoo.so.
> The source for libfoo has not changed.
> However, libfoo may have dependencies on libstdc++
> that mean that libfoo's ABI changes if/when libstdc++'s ABI changes
> and libfoo is recompiled with the new libstdc++.
> 

Is this any different from glibc? That is not a new problem. You just
have to deal with it. Sometimes, it may not be an easy thing to do. 


H.J.

Re: gcc 3.3

[Fergus Henderson]

On 30-Jul-2002, H. J. Lu <hjl@lucon.org> wrote:
> On Wed, Jul 31, 2002 at 07:41:09AM +1000, Fergus Henderson wrote:
> > 
> > P.S. I have a question of my own regarding symbol versioning.  Suppose I
> > have a C++ library `libfoo.so' that references libstdc++.so, and an
> > application `bar' that references both libfoo.so and libstdc++.so, and
> > suppose an ABI-breaking change is made to libstdc++.  A new version of
> > libstdc++ is installed; this has both the symbols for the new libstdc++
> > ABI, and symbols compatible with the old libstdc++ ABI, marked with the
> > old version number.  So `bar' continues to work.  Now, I try to compile
> > an application `baz' that references both libfoo.so and libstdc++.so.
> > `baz' uses the new version of the libstdc++.so ABI, but libfoo.so refers
> > to the old version.  To make `baz' work, I'd need to upgrade libfoo.so
> > to a version that uses the new version of the libstdc++.so ABI.  But that
> > would break `bar', wouldn't it?  (Or am I just hopelessly confused about
> 
> Why will the new libfoo.so break bar if it is binary compatible with
> the old libfoo.so?

It's not guaranteed to be binary compatible with the old libfoo.so.
The source for libfoo has not changed.
However, libfoo may have dependencies on libstdc++
that mean that libfoo's ABI changes if/when libstdc++'s ABI changes
and libfoo is recompiled with the new libstdc++.

For example, libfoo's interface may refer to types defined in libstdc++.
If the size of those types changes, then libfoo's ABI will change.

Even if libfoo's interface doesn't refer to any types defined in
libstdc++, there can still be problems.
The new libfoo.so refers to the new version of the libstdc++.so ABI.
But bar refers to the old version of the libstdc++.so ABI.
It may not be possible to combine the two in a single process.
For static objects whose size or layout has changed in incompatible ways,
it is not possible for both libfoo.so and bar to refer to the same object.

I guess things will work OK if you bump the major version number
on libfoo.so every time you compile it with a new version of libstdc++.
Then you can keep both the old and new versions of libfoo.so;
bar will continue to link with the old version, while baz
can link with the new version.

However, that approach will require either keeping around several
different versions of libfoo.so, or recompiling applications (such as bar)
that refer to it.  Furthermore, it means that library developers
are required to keep track of exactly which version of libstdc++
their binary libraries reference, so that they know to bump the major
version number when it changes.  They need to be aware that their
own ABI can change when they install a new version of libstdc++
which differs only in minor version number from the previous one.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: gcc 3.3

[H. J. Lu]

On Wed, Jul 31, 2002 at 07:41:09AM +1000, Fergus Henderson wrote:
> 
> P.S. I have a question of my own regarding symbol versioning.  Suppose I
> have a C++ library `libfoo.so' that references libstdc++.so, and an
> application `bar' that references both libfoo.so and libstdc++.so, and
> suppose an ABI-breaking change is made to libstdc++.  A new version of
> libstdc++ is installed; this has both the symbols for the new libstdc++
> ABI, and symbols compatible with the old libstdc++ ABI, marked with the
> old version number.  So `bar' continues to work.  Now, I try to compile
> an application `baz' that references both libfoo.so and libstdc++.so.
> `baz' uses the new version of the libstdc++.so ABI, but libfoo.so refers
> to the old version.  To make `baz' work, I'd need to upgrade libfoo.so
> to a version that uses the new version of the libstdc++.so ABI.  But that
> would break `bar', wouldn't it?  (Or am I just hopelessly confused about

Why will the new libfoo.so break bar if it is binary compatible with
the old libfoo.so?


H.J.

Re: gcc 3.3

[Jim Wilson]

>The hope is that yes, C++ compiled with gcc 3.3 will be binary compatible
>with 3.2.  However, there's no guarantees; if gcc 3.2 turns out to have
>ABI bugs, like 3.1 did, then they will need to be fixed.  The hope is
>that all the ABI bugs have now been caught, but no-one knows for sure.

PR 7442 submitted today reports more C++ ABI issues.  This one covers problems
with the cxxabi.h file.

There are also known back end problems that haven't been fixed yet.  We
use .init/.fini sections instead of .init_array/.fini_array sections for
static constructors/destructors.  We use .gnu.linkonce sections instead
of ELF COMDAT for template instantiation.  These should be fixable without
breaking backwards compatibility in theory, but we haven't tried yet.

I think we will continue to find C++ ABI bugs for a while.  There hasn't been
any attempt to verify the implementation against the specification.  I don't
think we should claim a stable C++ ABI until it is possible to link C++ code
compiled by gcc with C++ code compiled by other compilers, because only then
will we be able to test it.

Jim

Re: gcc 3.3

[Fergus Henderson]

On 30-Jul-2002, Chris M. Hickman <twoheadedboy@stonepool.com> wrote:
> I didn't see this addressed on the site...will 3.3 be binary compatible 
> with 3.2 (unlike 3.2>3.1)?

The hope is that yes, C++ compiled with gcc 3.3 will be binary compatible
with 3.2.  However, there's no guarantees; if gcc 3.2 turns out to have
ABI bugs, like 3.1 did, then they will need to be fixed.  The hope is
that all the ABI bugs have now been caught, but no-one knows for sure.

In addition, the libstdc++ ABI is not yet stable, so it is very
likely that there will be changes in libstdc++ that don't preserve the
libstdc++ ABI.  However, on platforms that support symbol versioning
(e.g. Linux), symbol versioning could in theory be used to reduce the
impact of such changes.  Note that symbol versioning is only a partial
solution; it can keep existing *executables* working with new versions
of libstdc++.so, but there may be problems with existing .so files,
.a files, or .o files that reference libstdc++.so.

(Why do you ask?)

P.S. I have a question of my own regarding symbol versioning.  Suppose I
have a C++ library `libfoo.so' that references libstdc++.so, and an
application `bar' that references both libfoo.so and libstdc++.so, and
suppose an ABI-breaking change is made to libstdc++.  A new version of
libstdc++ is installed; this has both the symbols for the new libstdc++
ABI, and symbols compatible with the old libstdc++ ABI, marked with the
old version number.  So `bar' continues to work.  Now, I try to compile
an application `baz' that references both libfoo.so and libstdc++.so.
`baz' uses the new version of the libstdc++.so ABI, but libfoo.so refers
to the old version.  To make `baz' work, I'd need to upgrade libfoo.so
to a version that uses the new version of the libstdc++.so ABI.  But that
would break `bar', wouldn't it?  (Or am I just hopelessly confused about
how symbol versioning works?)  Is there any simple way I can make `baz'
work without needing to recompile `bar', and without needing to bump
the libstdc++.so major version number?

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

gcc 3.3

[Chris M. Hickman]

I didn't see this addressed on the site...will 3.3 be binary compatible 
with 3.2 (unlike 3.2>3.1)?

Thanks for any info you can provide.

Chris