Re: gcc 3.5 integration branch proposal

Re: gcc 3.5 integration branch proposal

[Paul Koning]

>>>>> "Scott" == Scott Robert Ladd <coyote@coyotegulch.com> writes:

 Scott> Gabriel Dos Reis wrote:
 >> I suggest you spend some time in the bugzilla database, triaging
 >> bugs and explaining people who say that the compiler segfaulted --
 >> when compiling their programs, and you have determined that GCC
 >> was consuming huge memory -- that they are marginal.  Until then,
 >> I guess we're just going through an empty discussion.

 Scott> Well, people can tell me I'm nuttier than a fruitcake, but
 Scott> here's a wild suggestion:

 Scott> Define a "lean-and-mean" build, perhaps focused on C, that
 Scott> reduces system requirements and focuses on compilation
 Scott> speed. One of GCC's key advantages is its support for "older"
 Scott> hardware.

 Scott> Such an approach might go a long way toward satisfying the
 Scott> various constituencies who want faster compiles on limited
 Scott> systems.

It wouldn't satisfy me.  C++ is just as important as C, and it is
completely unreasonable to tell people that any host other than a
year or two is "marginal".

A point to keep in mind is that laptops make good hosts, but laptops
are more memory-limited than desktops. 

    paul

Re: gcc 3.5 integration branch proposal

[Robert Dewar]

Paul Koning wrote:

> It wouldn't satisfy me.  C++ is just as important as C, and it is
> completely unreasonable to tell people that any host other than a
> year or two is "marginal".
> 
> A point to keep in mind is that laptops make good hosts, but laptops
> are more memory-limited than desktops. 

Not really true these days. Most laptops have supported a gigabyte for
years, and most laptops of today support two gigabytes.

But that should be far beyond what is reasonably needed anyway. I think
what would be most helpful is to try to agree very specifically on what
is reasonable.

For example, we might say:

   All typical existing C++ code should be able to be compiled on a 256
   meg PC running GNU/Linux without significant thrashing.

That seems a reasonable expectation. Then we consider any violation of
this as a bug, to be fixed like any other bug.

Re: gcc 3.5 integration branch proposal

[Gabriel Dos Reis]

Robert Dewar <dewar@gnat.com> writes:

| For example, we might say:
| 
|    All typical existing C++ code should be able to be compiled on a 256
|    meg PC running GNU/Linux without significant thrashing.
| 
| That seems a reasonable expectation. Then we consider any violation of
| this as a bug, to be fixed like any other bug.

That is a good start :-) 

(But, I'm afraid there will be some divergence on what "typical" means.
Do we consider Gerald's testcase typical?  Do we consider template
constructs found in Boot typical?).

-- Gaby

Re: gcc 3.5 integration branch proposal

[Scott Robert Ladd]

Gabriel Dos Reis wrote:
> (But, I'm afraid there will be some divergence on what "typical" means.
> Do we consider Gerald's testcase typical?  Do we consider template
> constructs found in Boot typical?).

Assuming you mean "Boost" above -- no, I don't consider template 
gymnastics to be normal. Pathological, perhaps, but not normal.

In the interest of disclosure, I should not that I spent yesterday 
writing a very complex set of template metaprograms -- which, while 
necessary for performance, were also pathological and abnormal, IMHO. ;)

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: gcc 3.5 integration branch proposal

[Gabriel Dos Reis]

Scott Robert Ladd <coyote@coyotegulch.com> writes:

| Gabriel Dos Reis wrote:
| > (But, I'm afraid there will be some divergence on what "typical" means.
| > Do we consider Gerald's testcase typical?  Do we consider template
| > constructs found in Boot typical?).
| 
| Assuming you mean "Boost" above -- no, I don't consider template
| gymnastics to be normal. Pathological, perhaps, but not normal.

Yes I meant "Boost".  I also suspect that it has wide acceptance in
the C++ community.

| In the interest of disclosure, I should not that I spent yesterday
| writing a very complex set of template metaprograms -- which, while
| necessary for performance, were also pathological and abnormal,
| IMHO. ;)

I suspect that we all end up somewhere writing those "pathological and
abnormal" template constructs in typical codes ;-  )

-- Gaby

Re: gcc 3.5 integration branch proposal

[Robert Dewar]

Gabriel Dos Reis wrote:

> (But, I'm afraid there will be some divergence on what "typical" means.
> Do we consider Gerald's testcase typical?  Do we consider template
> constructs found in Boot typical?).

I would be very reluctant to declare any code that people actually write
and use as non-typical :-) It should be a last resort seldom resorted-to
to blame the programmer!

Re: gcc 3.5 integration branch proposal

[Giovanni Bajo]

Scott Robert Ladd wrote:

> Assuming you mean "Boost" above -- no, I don't consider template
> gymnastics to be normal. Pathological, perhaps, but not normal.

Well, the point about Boost is that they're meant to provide an easy interface
for the user. Thus, I can easily use boost::tuple just as I use std::pair
(without having to know many details about the monstrous metaprogramming
constructs it's built upon). The same applies for most numeric libraries, which
don't need much template programming experience *to be used*: they just happen
to generate very complex code because of stuff like lazy expression evaluation.

So, yes, I think that usage of many libraries in Boost qualify as normal C++.
They just happen to be very complex behind the curtains.

Giovanni Bajo

Re: gcc 3.5 integration branch proposal

[Paul Koning]

>>>>> "Robert" == Robert Dewar <dewar@gnat.com> writes:

 Robert> Paul Koning wrote:
 >> It wouldn't satisfy me.  C++ is just as important as C, and it is
 >> completely unreasonable to tell people that any host other than a
 >> year or two is "marginal".
 >> 
 >> A point to keep in mind is that laptops make good hosts, but
 >> laptops are more memory-limited than desktops.

 Robert> Not really true these days. Most laptops have supported a
 Robert> gigabyte for years, and most laptops of today support two
 Robert> gigabytes.

 Robert> But that should be far beyond what is reasonably needed
 Robert> anyway. I think what would be most helpful is to try to agree
 Robert> very specifically on what is reasonable.

Good.  My view on laptops is different from yours, but by adopting the
principle you suggest we don't have to sort out that difference.

 Robert> For example, we might say:

 Robert> All typical existing C++ code should be able to be compiled
 Robert> on a 256 meg PC running GNU/Linux without significant
 Robert> thrashing.

 Robert> That seems a reasonable expectation. Then we consider any
 Robert> violation of this as a bug, to be fixed like any other bug.

Another thing we'd want to be able to talk about is the minimum config
that will bootstrap gcc without a lot of thrashing.  For a while, that
config was dramatically larger than 256 (since it thrashed badly on my
384 meg laptop).

    paul

Re: gcc 3.5 integration branch proposal

[Russ Allbery]

Paul Koning <pkoning@equallogic.com> writes:

> Another thing we'd want to be able to talk about is the minimum config
> that will bootstrap gcc without a lot of thrashing.  For a while, that
> config was dramatically larger than 256 (since it thrashed badly on my
> 384 meg laptop).

I can report that it's not actually possible to bootstrap gcc on a DEC
Alpha with 64MB of memory any more.  GCC 2.95.3 managed, but GCC 3.3
doesn't.  I don't particularly care, though; it's a good excuse to get rid
of that system.  :)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: gcc 3.5 integration branch proposal

[Geoffrey Furnish]

Scott Robert Ladd <coyote at coyotegulch dot com> wrote:
 > Gabriel Dos Reis wrote:
 >  > Just for my education, what is insane use of C++?  IS Boots sane or
 >  > insane use of C++?
 > 
 > Insane, but useful and necessary for people who insist on using (or are 
 > required to use) C++ for heavy-duty array crunching. Such code is ugly, 
 > difficult to debug, and the only way C++ can approach Fortran 95's 
 > elegance. As such, a compiler needs to effectively handle template 
 > madness -- or we tell them all to use a *real* numerical language like 
 > Fortran 95 ;)

:-).  Well, I haven't atually studied the referenced code, but I'm guessing
this is a reference to use of expression templates.  I'd just like to point
out that such template "insanity" has applications that go far beyond array
processing.  

For example, on my current project we have employed "glommable expression
templates" to allow trivial augmentation of functors with ET status.  This
allows scan-and-classify loops that might ordinarily have been written with
quadruply nested compose/bind/select complexity, to be expressed with
trivially simple logical operators acting on functor predicates.

For example, to locate an element with properties ABC and QRS from a
sequence, we would say:

	  find_if( x.begin(), x.end(), IsABC() || IsQRS() );

instead of the more verbose STL predicate composer style.

You probably still think it's insane, but anyway my point is that it applies
far beyond numeric processing contexts.

Re: gcc 3.5 integration branch proposal

[Richard Earnshaw]

> > But on the other hand, caches were smaller, not backed by L2, and were
> > often allocate-on-write only (so zeroing a structure can be very
> 
> Did you mean to say allocate-on-read, or am I just confused beyond 
> words?
> 

Err, I meant to say that they were *not* allocate-on-write -- which 
amounts to about the same thing, yes.

R.

Re: gcc 3.5 integration branch proposal

[Segher Boessenkool]

> But on the other hand, caches were smaller, not backed by L2, and were
> often allocate-on-write only (so zeroing a structure can be very

Did you mean to say allocate-on-read, or am I just confused beyond 
words?

> expensive, especially if it is then re-initialized with other data).  
> All
> of these affect general approaches to what needs optimizing.

Amen.


Segher

Re: gcc 3.5 integration branch proposal

[Segher Boessenkool]

> Fundamentally, cutting down the write traffic even just to L1 can't be
> a bad thing.

It's only a bad thing if it causes actual L2 traffic.  Or when it is
fully redundant, of course ;-)


Segher

Re: gcc 3.5 integration branch proposal

[Segher Boessenkool]

> I don't see how making GCC faster on new machines wouldn't speed
> things up on slower machines.  Hmm...  Except for refraining from
> recomputing stuff over and over by setting aside some memory to hold
> the computed value.  This is fine for machines with lots of memory,

...and for machines with tiny caches, like the mentioned StrongARM.

Not all machines in the world have nicely balanced storage systems,
unfortunately.


Segher

Re: gcc 3.5 integration branch proposal

[Richard Earnshaw]

> 
> Typically, on older, slower machines (eg. the mentioned 300Mhz 
> StrongARM), memory accesses are relatively cheap relative to 
> computation.  Thus, on newer machines it's useful to perform some 
> computation if this results in smaller final data structures, but this 
> is not true on older machines.
> 

But on the other hand, caches were smaller, not backed by L2, and were 
often allocate-on-write only (so zeroing a structure can be very 
expensive, especially if it is then re-initialized with other data).  All 
of these affect general approaches to what needs optimizing.

R.

Re: gcc 3.5 integration branch proposal

[Zack Weinberg]

> Yes; this kind of logic is why many people waste a lot of time
> optimising the wrong place in their code.  Logically, deleting
> instructions means the processor has to do less work and therefore
> makes the program faster.  In practise, though, a write to L1 cache
> takes about 1/3 cycle, but a L2 cache miss takes ~100, and so L2 cache
> misses dominate execution time.

I don't dispute this, but when I see memset() in the top ten on a flat
profile, it seems hard to believe that reducing use of memset won't
speed things up.

zw

Re: gcc 3.5 integration branch proposal

[Alexandre Oliva]

On Jan 20, 2004, Geoffrey Keating <geoffk@apple.com> wrote:

> On 20/01/2004, at 2:11 PM, Alexandre Oliva wrote:

>> I don't see how making GCC faster on new machines wouldn't speed
>> things up on slower machines.  Hmm...  Except for refraining from
>> recomputing stuff over and over by setting aside some memory to hold
>> the computed value.

> Typically, on older, slower machines (eg. the mentioned 300Mhz
> StrongARM), memory accesses are relatively cheap relative to
> computation.

Which means not even the tuning for big-memory systems I suggested
would improve performance on newer hardware in detriment of older
hardware.

> Thus, on newer machines it's useful to perform some computation if
> this results in smaller final data structures, but this is not true
> on older machines.

But older machines generally have little memory too, so reducing data
structures can be good for them as well.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: gcc 3.5 integration branch proposal

[Zack Winkles]

Gerald Pfeifer <gerald@pfeifer.com> said:
> On Tue, 20 Jan 2004, Marc Espie wrote:
> > Show me anything that isn't Intel-based with this kind of
> > performance/cost ratio.
> 
> AMD offerings?

A bit anal here, eh?  I believe he meant x86, not Intel specifically.

Re: gcc 3.5 integration branch proposal

[Gerald Pfeifer]

On Tue, 20 Jan 2004, Marc Espie wrote:
> Show me anything that isn't Intel-based with this kind of performance/cost
> ratio.

AMD offerings?

> Then we'd better simply stop writing code for sparc64, powerpc, hppa,
> and declare them totally dead.

My personal view is that SPARC is going to die rather sooner than later
(if you see what Sun is doing and how badly these processors have been
performing for the last 9 years I've been following them) and hppa is a
dead end.  PowerPC, now that's something completely different!

I fully agree with you that we should strongly care about compile-time
performance -- and in fact I have been one of the strongest proponents
towards that end during the last couple of years.

However, I agree with Robert that there should be a minimum configuration
which we can assume, and if someone wants to use a VAX or a 80386 to run
GCC -- fine, but that cannot be our main focus.

Gerald
-- 
Gerald Pfeifer (Jerry)   gerald@pfeifer.com   http://www.pfeifer.com/gerald/

Re: gcc 3.5 integration branch proposal

[Mike Stump]

On Tuesday, January 20, 2004, at 02:06 PM, Alexandre Oliva wrote:
> Actually, it just requires the addition of the option of CFLAGS, which
> is fine, since it's a do-nothing should distcc choose to run locally.
> I really, really like it.

Well, you won't after you try them out.  Scaling is in the 6 (12 CPUs) 
machine range.  :-(  Turns out the preprocessing is very expensive.  
Could be PCH validation time...  Anyway, if you want better scaling, 
you'll need to track it down some.

If you want to see all my distcc patches, let me know...  I can email 
them, there are a few other random things...

Re: gcc 3.5 integration branch proposal

[Geoffrey Keating]

On 20/01/2004, at 2:11 PM, Alexandre Oliva wrote:

> On Jan 20, 2004, Geoffrey Keating <geoffk@apple.com> wrote:
>
>>> Err...  And under what kind of logic is getting the compiler slower
>>> not a waste of time for every GCC developer (that has to bootstrap 
>>> and
>>> test the whole thing for every patch) and user (that runs GCC to 
>>> build
>>> their own applications).
>
>> I didn't say the developer should make GCC slower.  I said the
>> developer should not worry about performance on *old* machines.
>> Performance on *new* machines is still a concern.  They are often not
>> the same thing.
>
> I don't see how making GCC faster on new machines wouldn't speed
> things up on slower machines.  Hmm...  Except for refraining from
> recomputing stuff over and over by setting aside some memory to hold
> the computed value.  This is fine for machines with lots of memory,
> but not for memory-starved machines, which are more likely to be the
> slow ones.  But then, for a sufficiently large testcase, setting such
> memory aside might cause even fast and big-memory boxes to get
> slower.
>
> Do you have other situations in mind?

Typically, on older, slower machines (eg. the mentioned 300Mhz 
StrongARM), memory accesses are relatively cheap relative to 
computation.  Thus, on newer machines it's useful to perform some 
computation if this results in smaller final data structures, but this 
is not true on older machines.

Re: gcc 3.5 integration branch proposal

[Alexandre Oliva]

On Jan 20, 2004, Geoffrey Keating <geoffk@apple.com> wrote:

>> Err...  And under what kind of logic is getting the compiler slower
>> not a waste of time for every GCC developer (that has to bootstrap and
>> test the whole thing for every patch) and user (that runs GCC to build
>> their own applications).

> I didn't say the developer should make GCC slower.  I said the
> developer should not worry about performance on *old* machines.
> Performance on *new* machines is still a concern.  They are often not
> the same thing.

I don't see how making GCC faster on new machines wouldn't speed
things up on slower machines.  Hmm...  Except for refraining from
recomputing stuff over and over by setting aside some memory to hold
the computed value.  This is fine for machines with lots of memory,
but not for memory-starved machines, which are more likely to be the
slow ones.  But then, for a sufficiently large testcase, setting such
memory aside might cause even fast and big-memory boxes to get
slower.

Do you have other situations in mind?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: gcc 3.5 integration branch proposal

[Alexandre Oliva]

On Jan 20, 2004, Mike Stump <mrs@apple.com> wrote:

>> How can you do PCH with distcc, if distcc just ships the preprocessed
>> sources to the remote box?

> :-)  You'd be interested in our magic -fpch-preprocess option.

Way cool!  I've either missed it or completely forgotten about it.

>> Usage of distcc simply disables PCH for me.  Are you hiding any
>> patches from the rest of us, that embed PCH data in the
>> preprocessor output?

> Yes.

But you were not hiding them, after all :-) :-)

Thanks for the pointer.

> No, it is fairly safe and not the default.  It does require that
> distcc know to put on one extra option, but I thought that was best,
> too many users of -E otherwise.

Actually, it just requires the addition of the option of CFLAGS, which
is fine, since it's a do-nothing should distcc choose to run locally.
I really, really like it.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: gcc 3.5 integration branch proposal

[Geoff Keating]

"Zack Weinberg" <zack@codesourcery.com> writes:

> Geoffrey Keating <geoffk@apple.com> writes:
> >> One cause of excessive memset that I have wanted to address for years
> >> is, make_node() clears the entire tree node - but make_node is almost
> >> always called from somewhere that's going to fill in most or all of
> >> the fields anyway.  We ought to have something like the gen_rtx_fmt_*
> >> functions for tree nodes.
> >
> > You're looking at this the wrong way.  We have to load the object into
> > cache anyway, it does not really matter if make_node does it or it's
> > done later.
> >
> > I'll emphasize Jan's comment: when you analyze GCC performance, you
> > can usually disregard all code that doesn't cause cache faults.
> 
> I think you misunderstand what I was saying, or else my testing is on
> chips with very different cache behavior.
> 
> The current effect is, make_node loads and zeroes the entire node, and
> then most fields of that are rewritten with live data.  I don't have
> numbers to say what that does for trees, but I know that cpplib used
> to do similar things to its own data structures, and changing it not
> to was good for an overall 1-2% on wall clock time running gcc -E.
> 
> Fundamentally, cutting down the write traffic even just to L1 can't be
> a bad thing.

Yes; this kind of logic is why many people waste a lot of time
optimising the wrong place in their code.  Logically, deleting
instructions means the processor has to do less work and therefore
makes the program faster.  In practise, though, a write to L1 cache
takes about 1/3 cycle, but a L2 cache miss takes ~100, and so L2 cache
misses dominate execution time.

Now, if you're cpplib, and you're zeroing a structure on the stack,
the arithmetic is different, since the stack is usually hot.  This is
not cpplib.

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

Re: gcc 3.5 integration branch proposal

[Mike Stump]

On Tuesday, January 20, 2004, at 11:03 AM, Alexandre Oliva wrote:
> Is the compiler server multi-threaded?

Nope.

> Even if it were, Mosix wouldn't get anything from it since threads 
> that run on a shared memory space don't migrate to different hosts.  
> At least last I
> looked, they didn't.

Right.  And since we don't (currently) share memory spaces, there isn't 
a problem.

> Sure, if you start multiple compile servers, they can migrate to
> different boxes.  Ditto for distcc builds.  But then each one
> duplicates some of the compilation that the compiler server is
> supposed to save, so by distributing the load you diminish the
> benefits of the sharing.

Yes, this is true.  The problem is, if the CPUs are idle, then in the 
amount they wait, waiting for one CPU to compute an answer, they could 
have computed it themselves and started compilation.  In addition to 
computing the answer, it would have to be shipped over the network as 
well, which just requires more resources.  But, yes, long term, it does 
make for an interesting research project.  What level of granularity is 
appropriate...  and how to manage it.

>> We do distcc and PCH today, perfectly compatible as well.
>
> How can you do PCH with distcc, if distcc just ships the preprocessed
> sources to the remote box?

:-)  You'd be interested in our magic -fpch-preprocess option.  It lets 
you ship a file that is 100x smaller, and requires 6x less processing.  
Check out http://gcc.gnu.org/ml/gcc/2003-03/msg00369.html and 
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00499.html  Anyway, 
eventually I'll submit it again...  Maybe in the coming year it might 
get in, here's to hoping.  We've been shipping it for a while now.

> Usage of distcc simply disables PCH for
> me.  Are you hiding any patches from the rest of us, that embed PCH
> data in the preprocessor output?

Yes.

> This might be nice, but it would probably be yet another incompatible 
> change in the preprocessor output format that might cause problems to 
> other tools.

No, it is fairly safe and not the default.  It does require that distcc 
know to put on one extra option, but I thought that was best, too many 
users of -E otherwise.

Re: gcc 3.5 integration branch proposal

[Alexandre Oliva]

On Jan 20, 2004, Mike Stump <mrs@apple.com> wrote:

> ?  Call me confused.  Give me a Mosix cluster and the compile server,
> and I'll show you fast compilation...

Is the compiler server multi-threaded?  Even if it were, Mosix
wouldn't get anything from it since threads that run on a shared
memory space don't migrate to different hosts.  At least last I
looked, they didn't.

Sure, if you start multiple compile servers, they can migrate to
different boxes.  Ditto for distcc builds.  But then each one
duplicates some of the compilation that the compiler server is
supposed to save, so by distributing the load you diminish the
benefits of the sharing.

> We do distcc and PCH today, perfectly compatible as well.

How can you do PCH with distcc, if distcc just ships the preprocessed
sources to the remote box?  Usage of distcc simply disables PCH for
me.  Are you hiding any patches from the rest of us, that embed PCH
data in the preprocessor output?  This might be nice, but it would
probably be yet another incompatible change in the preprocessor output
format that might cause problems to other tools.

> We don't do ccache and PCH, but I don't see why that is any harder
> than simple to get working.

If you do distcc, I don't see how you can not do ccache.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: gcc 3.5 integration branch proposal

[Zack Weinberg]

Geoffrey Keating <geoffk@apple.com> writes:
>> One cause of excessive memset that I have wanted to address for years
>> is, make_node() clears the entire tree node - but make_node is almost
>> always called from somewhere that's going to fill in most or all of
>> the fields anyway.  We ought to have something like the gen_rtx_fmt_*
>> functions for tree nodes.
>
> You're looking at this the wrong way.  We have to load the object into
> cache anyway, it does not really matter if make_node does it or it's
> done later.
>
> I'll emphasize Jan's comment: when you analyze GCC performance, you
> can usually disregard all code that doesn't cause cache faults.

I think you misunderstand what I was saying, or else my testing is on
chips with very different cache behavior.

The current effect is, make_node loads and zeroes the entire node, and
then most fields of that are rewritten with live data.  I don't have
numbers to say what that does for trees, but I know that cpplib used
to do similar things to its own data structures, and changing it not
to was good for an overall 1-2% on wall clock time running gcc -E.

Fundamentally, cutting down the write traffic even just to L1 can't be
a bad thing.

zw

Re: gcc 3.5 integration branch proposal

[Geoffrey Keating]

On 19/01/2004, at 6:43 PM, Alexandre Oliva wrote:

> On Jan 19, 2004, Geoff Keating <geoffk@apple.com> wrote:
>
>> On Jan 19, 2004, at 2:04 PM, Eric Botcazou wrote:
>>>> I would look at it this way: Why should a professional developer 
>>>> based
>>>> in the US try to make GCC work on anything less than this machine?
>>>> It's clearly not cost-effective to spend any significant time doing
>>>> so.
>>>
>>> My point of view is exactly reverse :-)  Why should a developer not
>>> keep GCC
>>> working on such a machine?
>
>> Because it's a waste of the developer's time?
>
> Err...  And under what kind of logic is getting the compiler slower
> not a waste of time for every GCC developer (that has to bootstrap and
> test the whole thing for every patch) and user (that runs GCC to build
> their own applications).

I didn't say the developer should make GCC slower.  I said the 
developer should not worry about performance on *old* machines.  
Performance on *new* machines is still a concern.  They are often not 
the same thing.

Re: gcc 3.5 integration branch proposal

[Geoffrey Keating]

On 20/01/2004, at 10:04 AM, Zack Weinberg wrote:

> Jan Hubicka <hubicka@ucw.cz> writes:
>
>>> I am not sure why ggc_alloc comes in second; checking is disabled so
>>
>> My experience from oprofiling is, that ggc_alloc/garbage
>> collector/memset is where all our cache faults go, so they end up
>> high in profiles even when amount of work looks small.  It is not
>> really ggc_alloc fault, rather it is the fact that we use too much
>> of it.
>
> True.
>
> One cause of excessive memset that I have wanted to address for years
> is, make_node() clears the entire tree node - but make_node is almost
> always called from somewhere that's going to fill in most or all of
> the fields anyway.  We ought to have something like the gen_rtx_fmt_*
> functions for tree nodes.

You're looking at this the wrong way.  We have to load the object into 
cache anyway, it does not really matter if make_node does it or it's 
done later.

I'll emphasize Jan's comment: when you analyze GCC performance, you can 
usually disregard all code that doesn't cause cache faults.

Re: gcc 3.5 integration branch proposal

[Zack Weinberg]

Jan Hubicka <hubicka@ucw.cz> writes:

>> I am not sure why ggc_alloc comes in second; checking is disabled so
>
> My experience from oprofiling is, that ggc_alloc/garbage
> collector/memset is where all our cache faults go, so they end up
> high in profiles even when amount of work looks small.  It is not
> really ggc_alloc fault, rather it is the fact that we use too much
> of it.

True.

One cause of excessive memset that I have wanted to address for years
is, make_node() clears the entire tree node - but make_node is almost
always called from somewhere that's going to fill in most or all of
the fields anyway.  We ought to have something like the gen_rtx_fmt_*
functions for tree nodes.

> I am working on some of these :)
> One other major stopper you don't see on your profile is
> for_each_template_parm that can eat about 10% when compiling Gerald's
> application with optimizing.

Oh, it's there even on this test case.  It's down at #54 on the call
graph, but it's responsible for two-thirds of the htab usage, which
you can see at the top of the profile.

zw

Re: gcc 3.5 integration branch proposal

[Karel Gardas]

On Tue, 20 Jan 2004, Daniel Jacobowitz wrote:

> On Tue, Jan 20, 2004 at 03:42:14PM +0100, Karel Gardas wrote:
> > [2]: COMO 4.3.3 + GCC 3.3.2 backend, -O0 optimize option (note that GCC
> >      is used as an ``assembler'' here, so the time to compile produced C
> >      code is not counted (i.e. como is ``just'' C++ to C compiler)
>
> You don't get to ignore that time.  C++ -> asm is much more complex
> than C++ -> C, so these numbers are meaningless.

I don't think so, but if you care, I can do comparison of:
como433+gcc332+as2.14 x gcc340+as2.14.

Cheers,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: gcc 3.5 integration branch proposal

[Daniel Jacobowitz]

On Tue, Jan 20, 2004 at 03:42:14PM +0100, Karel Gardas wrote:
> [2]: COMO 4.3.3 + GCC 3.3.2 backend, -O0 optimize option (note that GCC
>      is used as an ``assembler'' here, so the time to compile produced C
>      code is not counted (i.e. como is ``just'' C++ to C compiler)

You don't get to ignore that time.  C++ -> asm is much more complex
than C++ -> C, so these numbers are meaningless.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gcc 3.5 integration branch proposal

[Daniel Jacobowitz]

On Tue, Jan 20, 2004 at 11:08:39AM +0100, Jan Hubicka wrote:
> > I compiled GCC 3.4-to-be with profiling instrumentation and ran it

> > Each sample counts as 0.01 seconds.
> >   %   cumulative   self              self     total           
> >  time   seconds   seconds    calls   s/call   s/call  name    
> >   4.40      0.67     0.67      661     0.00     0.00  store_bindings
> >   2.95      1.12     0.45   372916     0.00     0.00  ggc_alloc

> > I am not sure why ggc_alloc comes in second; checking is disabled so

Because it's a small, frequently called function, and you used
profiling instrumentation, I'd assume.  This is famous for skewing
profiles.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gcc 3.5 integration branch proposal

[Paul Koning]

>>>>> "Mark" == Mark Hahn <hahn@physics.mcmaster.ca> writes:

 >> I think we can both agree that all is in the balance between code
 >> quality improvement and compilation speed degradation.

 Mark> the problem is that this discussion is being dominated by the
 Mark> sqeaky wheel phenomenon.  who's likley to complain about
 Mark> compiler speed?  people who somehow can't afford a beefy
 Mark> machine, and yet want to use gigantic UI frameworks or
 Mark> breathtaking template tricks.

 Mark> GCC still works VERY well for traditional Unix-style code, even
 Mark> on small machines, even with sane use of C++.

I suppose that's probably still true.  Our product is an embedded
system, about half C++, half C.  It's all pretty straightforward code,
some templates but nothing wild, certainly nothing likw what you
mentioned.

It does takes quite a while (a couple of hours) to do a full build.
We can do partial builds to deal with that, at some risk in getting
things out of sync.

What concerns me is that I see a general attitude that people who have
machines more than a year or two old are obsolete and shouldn't
complain when things get slow.  That attitude, if allowed to take
hold, will not hurt only those who do "breathtaking template tricks"
-- it may well affect anyone who builds any substantial size project
with GCC.

Something else to keep in mind: some people use PC hosts.  Others use
other hosts -- Solaris boxes for example.  It's easy for a US based PC
hacker to say "just spend a few hundred dollars on a new PC".  That
approach will not go over well in shops that use a different host
type, where host upgrades may be substantially more expensive.  Note
that switching hosts is only rarely an option.

I know that there are companies out there that build PC-only software,
whose minimal configuration requirements advance at least as rapidly
as the hardware state of the art.  Some of them even dominate the PC
business.  But it doesn't follow that the GCC project should follow
that example.  

     paul

Re: gcc 3.5 integration branch proposal

[Karel Gardas]

On Tue, 20 Jan 2004, Daniel Berlin wrote:

> As with the tests before, please make sure to --disable-checking when
> configuring 3.4.0.

Sure! checking is disabled:

thinkpad:/mnt/karel/mico/orb$ ~/usr/local/gcc-main/bin/c++ -v
Reading specs from
/home/karel/usr/local/gcc-main/lib/gcc/i686-pc-linux-gnu/3.4.0/specs
Configured with: ../gcc-main/configure
--prefix=/home/karel/usr/local/gcc-main --enable-shared --enable-threads
--enable-languages=c++ --disable-checking --enable-__cxa_atexit
Thread model: posix
gcc version 3.4.0 20040114 (experimental)
thinkpad:/mnt/karel/mico/orb$

Cheers,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: gcc 3.5 integration branch proposal

[Daniel Berlin]

> Nice, I'm just finishing download of icc8.0, anyway, como433 x gcc340
> testing is finished, just to show few interesting numbers here (the 
> full
> table comparison will be sent with icc8.0 results too):
>
>         	[1]	[2]	[3]
> pi.cc		17.53	5.58	-214.16
> pi_impl.cc	24.79	8.91	-178.23
> typecode_seq.cc	14.99	4.97	-201.61
> timebase.cc	14.44	4.94	-192.31
> ir.cc		53.89	12.62	-327.02
> ir_base.cc	17.64	5.52	-219.57
> imr.cc		23.93	6.4	-273.91
>
> [1]: GCC 3.4.0 as in previous tests -O0 optimize option

As with the tests before, please make sure to --disable-checking when 
configuring 3.4.0.
>

Re: gcc 3.5 integration branch proposal

[Karel Gardas]

On Tue, 20 Jan 2004, Laurent GUERBY wrote:

> On Tue, 2004-01-20 at 09:25, Karel Gardas wrote:
> > As a GCC user I'm insterested in as fast as possible C++ compiler. Guys,
> > this is a real pain to see how Comeau and/or Intel compiles faster than
> > GCC 3.3.x :-( (I'm sorry for this complain). And in addition I guess these
> > two are not the fastest C++ compilers in the industry... I was really
> > surprised seeing M$ VC 7.1 compiling much faster with all optimization
> > switch on than GCC at -O0 and even the code produced runs a bit faster
> > than those compiled by GCC with -O2...
>
> As requested by GCC developpers willing to care about your needs,
> please stop posting undocumented impressions and start submitting fully
> documented (version, compile/exec times, flags, code) cases in bugzilla.
>
> One of the only cases (C) with data posted so far between ICC and GCC
> was showing current GCC compiling FASTER.
>
> <<
>
>                     compile  benchmark
>                      time      time
>                    --------  ---------
> gcc mainline        1:43      7:59
>    w/ -mfpmath=sse   1:46      6:30
>
> gcc tree-ssa        1:46      7:35
>    w/ -mfpmath=sse  ** SEG fault **
>
> icc 8.0             1:53      5:50
> >>
>
> 1:46 is faster than 1:53, sorry.

Nice, I'm just finishing download of icc8.0, anyway, como433 x gcc340
testing is finished, just to show few interesting numbers here (the full
table comparison will be sent with icc8.0 results too):

        	[1]	[2]	[3]
pi.cc		17.53	5.58	-214.16
pi_impl.cc	24.79	8.91	-178.23
typecode_seq.cc	14.99	4.97	-201.61
timebase.cc	14.44	4.94	-192.31
ir.cc		53.89	12.62	-327.02
ir_base.cc	17.64	5.52	-219.57
imr.cc		23.93	6.4	-273.91

[1]: GCC 3.4.0 as in previous tests -O0 optimize option
[2]: COMO 4.3.3 + GCC 3.3.2 backend, -O0 optimize option (note that GCC
     is used as an ``assembler'' here, so the time to compile produced C
     code is not counted (i.e. como is ``just'' C++ to C compiler)
[3]: delta in %

As I said, stay tuned to see more results! :-)

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: gcc 3.5 integration branch proposal

[Scott Robert Ladd]

Gabriel Dos Reis wrote:
 > Just for my education, what is insane use of C++?  IS Boots sane or
 > insane use of C++?

Insane, but useful and necessary for people who insist on using (or are 
required to use) C++ for heavy-duty array crunching. Such code is ugly, 
difficult to debug, and the only way C++ can approach Fortran 95's 
elegance. As such, a compiler needs to effectively handle template 
madness -- or we tell them all to use a *real* numerical language like 
Fortran 95 ;)

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: gcc 3.5 integration branch proposal

[Scott Robert Ladd]

Mike Stump wrote:
> Yes, but the sad thing is that I suspect it is 50% slower or more on a 8 
> GHz machine as well, in fact, I wonder if it is worse than 50% slower.

What do we gain in terms of language support and generated code speed, 
in return for slower compile times? We keep talking about C++, but C 
compile times have slowed too...

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: gcc 3.5 integration branch proposal

[Laurent GUERBY]

On Tue, 2004-01-20 at 09:25, Karel Gardas wrote:
> As a GCC user I'm insterested in as fast as possible C++ compiler. Guys,
> this is a real pain to see how Comeau and/or Intel compiles faster than
> GCC 3.3.x :-( (I'm sorry for this complain). And in addition I guess these
> two are not the fastest C++ compilers in the industry... I was really
> surprised seeing M$ VC 7.1 compiling much faster with all optimization
> switch on than GCC at -O0 and even the code produced runs a bit faster
> than those compiled by GCC with -O2...

As requested by GCC developpers willing to care about your needs,
please stop posting undocumented impressions and start submitting fully
documented (version, compile/exec times, flags, code) cases in bugzilla.

One of the only cases (C) with data posted so far between ICC and GCC
was showing current GCC compiling FASTER.

<<

                    compile  benchmark
                     time      time
                   --------  ---------
gcc mainline        1:43      7:59
   w/ -mfpmath=sse   1:46      6:30

gcc tree-ssa        1:46      7:35
   w/ -mfpmath=sse  ** SEG fault **

icc 8.0             1:53      5:50
>>

1:46 is faster than 1:53, sorry.

Laurent

Re: gcc 3.5 integration branch proposal

[Jan Hubicka]

> Nick Burrett <nick@dsvr.net> writes:
> > There's no harm in that.  I have a port of GCC 3.3.3 running on a
> > 200MHz StrongARM that takes over 6 minutes to compile the following:
> >
> >     #include <iostream>
> >
> >     int main (void)
> >     {
> >       std::cout << "Hello World" << std::endl;
> >       return 0;
> >     }
> >
> > GCC 2.95.4 compiled the same application on the same hardware in
> > around 20-30 seconds.
> 
> I compiled GCC 3.4-to-be with profiling instrumentation and ran it
> against this test case.  The test takes 2.7 seconds on my roughly
> two-year-old Athlon, which I think is far too slow; it should be
> <0.01s on this hardware.  Without benefit of PCH or other such
> cleverness.
> 
> Profiling results are interesting.  First, the times are nearly
> identical at -O2 and -fsyntax-only.  This is natural, there really
> isn't anything here to optimize, but it's worth noting.  Almost all
> the time is in the C++ front end.  Here's the top of the flat profile
> (-fsyntax-only):
> 
> Each sample counts as 0.01 seconds.
>   %   cumulative   self              self     total           
>  time   seconds   seconds    calls   s/call   s/call  name    
>   4.40      0.67     0.67      661     0.00     0.00  store_bindings
>   2.95      1.12     0.45   372916     0.00     0.00  ggc_alloc
>   2.95      1.57     0.45   129400     0.00     0.00  make_node
>   2.50      1.95     0.38   193075     0.00     0.00  _cpp_lex_direct
>   2.36      2.31     0.36    14689     0.00     0.00  grokdeclarator
>   2.30      2.66     0.35   103752     0.00     0.00  memset
>   2.23      3.00     0.34    96832     0.00     0.00  ht_lookup
>   1.90      3.29     0.29   365671     0.00     0.00  htab_find_slot_with_hash
>   1.90      3.58     0.29    89353     0.00     0.00  walk_tree
>   1.90      3.87     0.29    81277     0.00     0.00  _int_malloc
> 
> store_bindings potentially does a tremendous amount of work: it (in
> conjunction with its sole caller, maybe_push_to_top_level) temporarily
> unwinds the current scope stack, which entails modifying the data
> structure for every identifier declared in the program.  Since the
> program declares some 8,000 identifiers, you can see why a function
> that's called only 661 times ends up at the top of the profile.
> 
> I am not sure why ggc_alloc comes in second; checking is disabled so

My experience from oprofiling is, that ggc_alloc/garbage
collector/memset is where all our cache faults go, so they end up high
in profiles even when amount of work looks small.
It is not really ggc_alloc fault, rather it is the fact that we use too
much of it.

> it isn't doing tons and tons of memset() operations or anything.  The
> time spent in make_node is, I suspect, largely due to the inlined
> memset in there.  Memset itself is being called mostly by [x]calloc,
> and most of *those* calls trace back to walk_tree_without_duplicates
> and/or for_each_template_parm, via htab_create_alloc.  Those hash
> tables are a kludge to prevent exponential time consumption in certain
> algorithms; it would be nice if they weren't necessary.
> 
> I think there's room for some easy speedups here, and I think they
> could get into 3.4 if developed promptly.  Let's see some patches.

I am working on some of these :)
One other major stopper you don't see on your profile is
for_each_template_parm that can eat about 10% when compiling Gerald's
application with optimizing.

Honza
> 
> zw

Re: gcc 3.5 integration branch proposal

[Karel Gardas]

On Mon, 19 Jan 2004, Mark Hahn wrote:

> IMO, GCC should ignore compiler performance unless regressions are >= 2x.

E.g. so 1.5 slower GCC 3.4 in comparison with GCC 3.3 is ok, and then 1.5
slower GCC 3.5 in comparison with GCC 3.4 is again ok, etc, etc? Do you
mean this?

> and when a tradeoff is necessary, 5% better code is worth 2x compile time.
> obviously, I'm interested in code that is run more often than compiled.

As a GCC user I'm insterested in as fast as possible C++ compiler. Guys,
this is a real pain to see how Comeau and/or Intel compiles faster than
GCC 3.3.x :-( (I'm sorry for this complain). And in addition I guess these
two are not the fastest C++ compilers in the industry... I was really
surprised seeing M$ VC 7.1 compiling much faster with all optimization
switch on than GCC at -O0 and even the code produced runs a bit faster
than those compiled by GCC with -O2...

> but isn't that the whole point of a compiler?  maybe another factor is people
> trying to use GCC where they should use a scripting language instead.

I guess you have forgotten that compiler is also needed for software
_development_.

Cheers,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: gcc 3.5 integration branch proposal

[Marc Espie]

On Mon, Jan 19, 2004 at 10:45:09PM -0500, Robert Dewar wrote:
> Marc Espie wrote:

> >Maybe most of you are actually working for companies, and so don't really
> >care about the toll in terms of human costs ? I mean, sure, hire a new
> >programmer, or buy a new $2000 machine. But real hobbyists ?   We don't
> >really have ways to hire new people. And a new $2000 machine means less
> >network cards or gfx cards to play with and port drivers to.

> Please don't make strawmen. As my previous message made clear, the 
> figure of $2000 is bogus, $400 is sufficient, and that *included* a
> 17" monitor and the license fee for XP.

Show me anything that isn't Intel-based with this kind of performance/cost
ratio.

Do you think it doesn't matter ?

Then we'd better simply stop writing code for sparc64, powerpc, hppa,
and declare them totally dead.

Re: gcc 3.5 integration branch proposal

[D. Starner]

> But that is not the FreeDOM that the FSF is taking about.

If you want to quote verse, try:

    Software developers typically consider these questions on
    the assumption that the criterion for the answer is to 
    maximize developers' profits. The political power of 
    business has led to the government adoption of both this
    criterion and the answer proposed by the developers: that 
    the program has an owner, typically a corporation 
    associated with its development. 

    I would like to consider the same question using a 
    different criterion: the prosperity and freedom of the 
    public in general. 

What maximizes the prosperity and freedom of the public in
general: a compiler (and hence all the Free operating systems
that depend on it) requiring continous upgrades if they want
to be able to use the source (the point of Free software), or
a compiler and Free operating system that can be compiled and
used on their current computer? Is RMS's public only that 
subset of the public that can afford to spend $400 on a 
computer every year?

In any case, my message wasn't about the philosophy of Free
software. It was about the pragmatic needs of many of the
users of Free software, and in my case the pragmatic needs
of a Debian developer.

-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: gcc 3.5 integration branch proposal

[Eric Botcazou]

> Eric, you are becoming a bit extreme at this stage.

Admittedly.  Note, however, that there was a smiley.

-- 
Eric Botcazou

Re: gcc 3.5 integration branch proposal

[Robert Dewar]

Eric Botcazou wrote:
>>>My point of view is exactly reverse :-)  Why should a developer not
>>>keep GCC working on such a machine?
>>
>>Because it's a waste of the developer's time?
> 
> 
> Or laziness? ;-)

Eric, you are becoming a bit extreme at this stage. No, it is not lazy
to organize your resources effectively and avoid wasting time on goals
that simply are unrealistic and make little sense. Time wasted trying
to get GCC working on obsolete machines is time taken away from more
important tasks.

Re: gcc 3.5 integration branch proposal

[Zack Weinberg]

Nick Burrett <nick@dsvr.net> writes:
> There's no harm in that.  I have a port of GCC 3.3.3 running on a
> 200MHz StrongARM that takes over 6 minutes to compile the following:
>
>     #include <iostream>
>
>     int main (void)
>     {
>       std::cout << "Hello World" << std::endl;
>       return 0;
>     }
>
> GCC 2.95.4 compiled the same application on the same hardware in
> around 20-30 seconds.

I compiled GCC 3.4-to-be with profiling instrumentation and ran it
against this test case.  The test takes 2.7 seconds on my roughly
two-year-old Athlon, which I think is far too slow; it should be
<0.01s on this hardware.  Without benefit of PCH or other such
cleverness.

Profiling results are interesting.  First, the times are nearly
identical at -O2 and -fsyntax-only.  This is natural, there really
isn't anything here to optimize, but it's worth noting.  Almost all
the time is in the C++ front end.  Here's the top of the flat profile
(-fsyntax-only):

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
  4.40      0.67     0.67      661     0.00     0.00  store_bindings
  2.95      1.12     0.45   372916     0.00     0.00  ggc_alloc
  2.95      1.57     0.45   129400     0.00     0.00  make_node
  2.50      1.95     0.38   193075     0.00     0.00  _cpp_lex_direct
  2.36      2.31     0.36    14689     0.00     0.00  grokdeclarator
  2.30      2.66     0.35   103752     0.00     0.00  memset
  2.23      3.00     0.34    96832     0.00     0.00  ht_lookup
  1.90      3.29     0.29   365671     0.00     0.00  htab_find_slot_with_hash
  1.90      3.58     0.29    89353     0.00     0.00  walk_tree
  1.90      3.87     0.29    81277     0.00     0.00  _int_malloc

store_bindings potentially does a tremendous amount of work: it (in
conjunction with its sole caller, maybe_push_to_top_level) temporarily
unwinds the current scope stack, which entails modifying the data
structure for every identifier declared in the program.  Since the
program declares some 8,000 identifiers, you can see why a function
that's called only 661 times ends up at the top of the profile.

I am not sure why ggc_alloc comes in second; checking is disabled so
it isn't doing tons and tons of memset() operations or anything.  The
time spent in make_node is, I suspect, largely due to the inlined
memset in there.  Memset itself is being called mostly by [x]calloc,
and most of *those* calls trace back to walk_tree_without_duplicates
and/or for_each_template_parm, via htab_create_alloc.  Those hash
tables are a kludge to prevent exponential time consumption in certain
algorithms; it would be nice if they weren't necessary.

I think there's room for some easy speedups here, and I think they
could get into 3.4 if developed promptly.  Let's see some patches.

zw

Re: gcc 3.5 integration branch proposal

[Robert Dewar]

Marc Espie wrote:

> Maybe most of you are actually working for companies, and so don't really
> care about the toll in terms of human costs ? I mean, sure, hire a new
> programmer, or buy a new $2000 machine. But real hobbyists ?   We don't
> really have ways to hire new people. And a new $2000 machine means less
> network cards or gfx cards to play with and port drivers to.

Please don't make strawmen. As my previous message made clear, the 
figure of $2000 is bogus, $400 is sufficient, and that *included* a
17" monitor and the license fee for XP.

Re: gcc 3.5 integration branch proposal

[Andrew Pinski]

On Jan 19, 2004, at 19:00, D. Starner wrote:

>> That's a pretty reasonable machine at a very reasonable
>> price. I know it's a little ahead of what some people might
>> have, but I think it is still a reasonable benchmark machine.
>
> There are many people running *BSD and Linux machines who may
> not be doing heavy development, but still need to compile the
> latest mplayer or Mozilla sources. Some of them are students
> who have a completely working machine, virtually no income
> and no need to buy a new computer besides GCC. GCC and mplayer
> are the only two programs which tax my five year old CPU over
> twenty seconds. Saying I should just spend $400 to upgrade
> a machine that works just fine to support an application which
> ran on a VAX just fine at one point in time seems a little
> unreasonable.


But that is not the FreeDOM that the FSF is taking about.

 From <http://www.gnu.org/philosophy/free-software-for-freedom.html>:
But the explanation for ``free software'' is simple--a person who has 
grasped the idea of ``free speech, not free beer'' will not get it 
wrong again. There is no such succinct way to explain the official 
meaning of ``open source'' and show clearly why the natural definition 
is the wrong one.


Thanks,
Andrew Pinski

Re: gcc 3.5 integration branch proposal

[Mike Stump]

On Monday, January 19, 2004, at 06:43 PM, Alexandre Oliva wrote:
> I know Apple has put a lot of effort on speeding up the compiler, and
> I can only find it sad that such efforts are fundamentally
> incompatible with the relatively-scalable approach to speeding builds
> up, namely, the use of compiler farms with distcc, Mosix or similar
> techniques.

?  Call me confused.  Give me a Mosix cluster and the compile server, 
and I'll show you fast compilation...  What parts of it do you think 
are incompatible?  We do distcc and PCH today, perfectly compatible as 
well.  We don't do ccache and PCH, but I don't see why that is any 
harder than simple to get working.

I'm wanna try my hand at ccache built into the compile server on a 64 
bit machine and see how well it works in practice...  :-)  Certainly I 
see 100x+ speedups now with it with small testcases.

PCH and the compile server are playing together nicer than I'd imagine.

Anyone have a Mosix cluster they want to donate some time on?  :-)

Are you by chance referring to the fact that we don't do fine gained db 
in the compiler's data structures and share those across compile 
servers?  If so, I'm yet to be convinced that that would be wise to do. 
  Maybe.  If it is, it isn't fundamentally incompatible, in fact, it is 
a possibly planned development line, it just won't be in the first 
version checked into mainline.

Re: gcc 3.5 integration branch proposal

[D. Starner]

> That's a pretty reasonable machine at a very reasonable 
> price. I know it's a little ahead of what some people might 
> have, but I think it is still a reasonable benchmark machine.

There are many people running *BSD and Linux machines who may 
not be doing heavy development, but still need to compile the
latest mplayer or Mozilla sources. Some of them are students
who have a completely working machine, virtually no income
and no need to buy a new computer besides GCC. GCC and mplayer
are the only two programs which tax my five year old CPU over
twenty seconds. Saying I should just spend $400 to upgrade
a machine that works just fine to support an application which
ran on a VAX just fine at one point in time seems a little 
unreasonable.

David Starner - dvdeug@debian.org
-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: gcc 3.5 integration branch proposal

[Alexandre Oliva]

On Jan 19, 2004, espie@quatramaran.ens.fr (Marc Espie) wrote:

> with gcc-head:

--disable-checking?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: gcc 3.5 integration branch proposal

[Alexandre Oliva]

On Jan 19, 2004, Geoff Keating <geoffk@apple.com> wrote:

> On Jan 19, 2004, at 2:04 PM, Eric Botcazou wrote:
>>> I would look at it this way: Why should a professional developer based
>>> in the US try to make GCC work on anything less than this machine?
>>> It's clearly not cost-effective to spend any significant time doing
>>> so.
>> 
>> My point of view is exactly reverse :-)  Why should a developer not
>> keep GCC
>> working on such a machine?

> Because it's a waste of the developer's time?

Err...  And under what kind of logic is getting the compiler slower
not a waste of time for every GCC developer (that has to bootstrap and
test the whole thing for every patch) and user (that runs GCC to build
their own applications).

Sure, one can get beefier hardware.  But there's a limit to that, and
making the compiler slower just because it still bootstraps in under 2
hours on a reasonable machine for US standards can make a project that
used to build overnight to no longer complete the build when people
get back to work on the next day.  Sure, you can then start throwing
other tricks into the problem, like ccache and distcc in compiler
farms, but this means additional costs.  So we're actually imposing a
tax on everybody who wants to use the newer compiler by not caring
about its performance.

I know Apple has put a lot of effort on speeding up the compiler, and
I can only find it sad that such efforts are fundamentally
incompatible with the relatively-scalable approach to speeding builds
up, namely, the use of compiler farms with distcc, Mosix or similar
techniques.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: gcc 3.5 integration branch proposal

[Mike Stump]

On Monday, January 19, 2004, at 02:40 AM, Nick Burrett wrote:
> There's no harm in that.  I have a port of GCC 3.3.3 running on a 
> 200MHz StrongARM that takes over 6 minutes to compile the following:
>
>    #include <iostream>
>
>    int main (void)
>    {
>      std::cout << "Hello World" << std::endl;
>      return 0;
>    }
>
> GCC 2.95.4 compiled the same application on the same hardware in 
> around 20-30 seconds.

Now, try that with a hot PCH file for iostream.  I predict 20 seconds.  
:-)

Re: gcc 3.5 integration branch proposal

[Mike Stump]

On Monday, January 19, 2004, at 12:38 PM, Robert Dewar wrote:
> My goodness, I would not even *consider* asking a professional 
> developer
> (someone whose time is worth in the region of $1000 a day to a typical
> company) to use this low end machine. So we sure have totally different
> perspectives.

Yes, but the sad thing is that I suspect it is 50% slower or more on a 
8 GHz machine as well, in fact, I wonder if it is worse than 50% slower.

Re: gcc 3.5 integration branch proposal

[Gabriel Dos Reis]

Mark Hahn <hahn@physics.mcmaster.ca> writes:

| > I think we can both agree that all is in the balance between code quality 
| > improvement and compilation speed degradation.
| 
| the problem is that this discussion is being dominated by the sqeaky wheel
| phenomenon.  who's likley to complain about compiler speed?  people who 
| somehow can't afford a beefy machine, and yet want to use gigantic UI
| frameworks or breathtaking template tricks.

Last time Gerald generously offered me a guesst account for debugging
a regression I introduced in the compiler, I determined that the
machine had at least 1Gb ram.  I suppose you don't regard such
machine as beefy? Or do you think Gerald's testcase is using
gigantic UI framework or breathtaking template tricks? 

| GCC still works VERY well for traditional Unix-style code, even on small
| machines, even with sane use of C++.

Just for my education, what is insane use of C++?  IS Boots sane or
insane use of C++?

Thanks,

-- Gaby

Re: gcc 3.5 integration branch proposal

[Mark Hahn]

> I think we can both agree that all is in the balance between code quality 
> improvement and compilation speed degradation.

the problem is that this discussion is being dominated by the sqeaky wheel
phenomenon.  who's likley to complain about compiler speed?  people who 
somehow can't afford a beefy machine, and yet want to use gigantic UI
frameworks or breathtaking template tricks.

GCC still works VERY well for traditional Unix-style code, even on small
machines, even with sane use of C++.

the real problem is not that gcc sometimes compiles a little slower,
but that so very many people have abandoned GCC in favor of the better
performance, F90 support and OpenMP available in Intel's compilers.

IMO, GCC should ignore compiler performance unless regressions are >= 2x.
and when a tradeoff is necessary, 5% better code is worth 2x compile time.
obviously, I'm interested in code that is run more often than compiled.

but isn't that the whole point of a compiler?  maybe another factor is people
trying to use GCC where they should use a scripting language instead.

regards, mark hahn.

Re: gcc 3.5 integration branch proposal

[Laurent GUERBY]

On Mon, 2004-01-19 at 23:28, Marc Espie wrote:
> On Mon, Jan 19, 2004 at 11:08:15PM +0100, Laurent GUERBY wrote:
> > BTW, people with old machines always have the choice of staying with old
> > software too.
> 
> Not really. Not when you want to compile similar stuff on a wide range
> of machine. It's not as if you have a choice of `small optimizations,
> fast compiler, correct compiler'. Staying with gcc 2.95 comes with the
> price of being completely unable to even compile standard C++ code.

Ok, so you're comparing a not working compiler just able to compile
faster small parts of the code you're interested in with a compiler
able to compile everything but slower? I don't know C++ much, but it
looks like being correct and not horribly inefficient in generated code
in the C++ compiler world is very expensive in terms of CPU cycles.

> Maybe what we're doing with the OpenBSD project is somewhat unusual ?
> but we've found out in the past that each new compiler has its share
> of arch-dependent and arch-independent bug. There comes a point where
> you prefer to have one single compiler, because that way at least,
> you have to cope with just one set of arch-independent bugs.

I must admit I would give a hard try at cross compiling from
fast x86 machines to your targets and then testing
the resulting images on the target machines in various automated ways
(hardware performance allowing of course but if generated code is faster
with newer GCC you should be able to test more in less time :), but I
have no experience in OS building and testing so that might not be
reasonable.

> Right now, we're probably going to end with both gcc 2.95.3 and gcc 3.3.2
> active on different architectures at the same time, and the price in terms
> of maintenance is steep.

That's price of your team time for your users against price of GCC
developpers time for GCC users. Everyone should be able to make
his/her mind while considering the whole free software community.

> Maybe most of you are actually working for companies, and so don't really
> care about the toll in terms of human costs ? I mean, sure, hire a new
> programmer, or buy a new $2000 machine. But real hobbyists ?   We don't
> really have ways to hire new people. And a new $2000 machine means less
> network cards or gfx cards to play with and port drivers to.

At work cost of reasonable developper machines is less than cost of
professional support for GCC for our team and targets paid to ACT
and so used in part to improve GCC too. We have also 30 processors used
for developping our software and more than 500 processors for running
our software. Math is not really hard to do there.

At home, I change machine every two or three years, donate the old
machine to FSF if needed. My current machine is an Athlon 2600 with 512
MB RAM and 120 GB disk I paid less than 500 euros in november last year.
GCC boostrap is less than 30 minutes for c,ada.

Laurent

Re: gcc 3.5 integration branch proposal

[Gabriel Dos Reis]

Dale Johannesen <dalej@apple.com> writes:

| > We should probably require developers to use slow machines with small
| > rams.  Semi ;-)
| 
| I know of 3 companies that tried this strategy at some point, on the
| theory that
| turnaround time on minimal machines was important.
| All 3 of them relented when they saw how unproductive their developers
| were.

As noted elsewhere, software expertise has changed axes ;-)

Re: gcc 3.5 integration branch proposal

[Eric Botcazou]

> > My point of view is exactly reverse :-)  Why should a developer not
> > keep GCC working on such a machine?
>
> Because it's a waste of the developer's time?

Or laziness? ;-)

-- 
Eric Botcazou

Re: gcc 3.5 integration branch proposal

[Marc Espie]

On Mon, Jan 19, 2004 at 11:08:15PM +0100, Laurent GUERBY wrote:
> BTW, people with old machines always have the choice of staying with old
> software too.

Not really. Not when you want to compile similar stuff on a wide range
of machine. It's not as if you have a choice of `small optimizations,
fast compiler, correct compiler'. Staying with gcc 2.95 comes with the
price of being completely unable to even compile standard C++ code.

Maybe what we're doing with the OpenBSD project is somewhat unusual ?
but we've found out in the past that each new compiler has its share
of arch-dependent and arch-independent bug. There comes a point where
you prefer to have one single compiler, because that way at least,
you have to cope with just one set of arch-independent bugs.

Right now, we're probably going to end with both gcc 2.95.3 and gcc 3.3.2
active on different architectures at the same time, and the price in terms
of maintenance is steep.

Maybe most of you are actually working for companies, and so don't really
care about the toll in terms of human costs ? I mean, sure, hire a new
programmer, or buy a new $2000 machine. But real hobbyists ?   We don't
really have ways to hire new people. And a new $2000 machine means less
network cards or gfx cards to play with and port drivers to.

That's part of the price of having a strongly coupled front-end and
back-end, I guess.

So, old architectures will stop when/if we switch to a slower GCC.

In such a case `keeping old software' == dead architecture. Thoroughly.
I wouldn't even dream of still running OpenBSD 3.1 today, judging by
the number of bugs we've fixed since then, and since the focus of
OpenBSD is still on security...

Re: gcc 3.5 integration branch proposal

[Geoff Keating]

On Jan 19, 2004, at 2:04 PM, Eric Botcazou wrote:

>> I would look at it this way: Why should a professional developer based
>> in the US try to make GCC work on anything less than this machine?
>> It's clearly not cost-effective to spend any significant time doing 
>> so.
>
> My point of view is exactly reverse :-)  Why should a developer not 
> keep GCC
> working on such a machine?

Because it's a waste of the developer's time?

-- 
Geoff Keating <geoffk@apple.com>

Re: gcc 3.5 integration branch proposal

[Laurent GUERBY]

On Mon, 2004-01-19 at 22:46, Eric Botcazou wrote:
> I think we can both agree that all is in the balance between code quality 
> improvement and compilation speed degradation.

FWIW, I'd gladly accept compilation being 2-3 times slower for a 5-10%
gain in execution speed at high optimisation levels,
from both my home user and work user point of view.

At low optimisation levels, I'd love a switch that makes optimisations
that are somewhat cheap relatively to -O2/3 at the compile time level,
reduce generated code and debug information size for faster linking than
-O0 and still allow perfect debugging ("-Od"?).

BTW, people with old machines always have the choice of staying with old
software too.

Laurent

Re: gcc 3.5 integration branch proposal

[Eric Botcazou]

> I would look at it this way: Why should a professional developer based
> in the US try to make GCC work on anything less than this machine?
> It's clearly not cost-effective to spend any significant time doing so.

My point of view is exactly reverse :-)  Why should a developer not keep GCC 
working on such a machine?  I think it may have been partially shared by the 
SC, because there used to be a criterion for compilation time degradation 
between releases (15% IIRC).  Was it even checked once?

-- 
Eric Botcazou

Re: gcc 3.5 integration branch proposal

[Eric Botcazou]

> And perhaps the improvement in code quality indicates that there is
> something right in the development process.

I think we can both agree that all is in the balance between code quality 
improvement and compilation speed degradation.

-- 
Eric Botcazou

Re: gcc 3.5 integration branch proposal

[Geoff Keating]

On Jan 19, 2004, at 12:21 PM, Eric Botcazou wrote:

>> Here is a suggestion:
>>
>> For $399 you can buy from Dell a brand new Dimension 2400 with a 
>> 2.4GHz
>> Celeron, 400MHz front bus, 256 meg of memory, 40GB disk, 17" monitor,
>> and 48x CD-RW/DVD-ROM combo drive.
>
> I have always been amazed by the reasonings starting with "you can 
> buy".  Why
> in the first place should you buy a brand new computer to do anything? 
>  Why
> can't the typical 2-3 years old model be sufficient?
>
>> That's a pretty reasonable machine at a very reasonable price.
>
> For a professional developer based in the US, certainly.  I'm not sure 
> GCC
> should primarily target such a population though.

I would look at it this way: Why should a professional developer based 
in the US try to make GCC work on anything less than this machine?  
It's clearly not cost-effective to spend any significant time doing so.

-- 
Geoff Keating <geoffk@apple.com>

Re: gcc 3.5 integration branch proposal

[Robert Dewar]

Eric Botcazou wrote:

> Let's face it: from the user viewpoint (all is in the viewpoint :-), during 
> the past few years, GCC has exchanged a reasonably good code quality coupled 
> with a good compilation speed for a slightly better code quality and a 
> catastrophic compilation speed.
   ^^^^^^^^^^^^

That's unjustified exaggeration. We have a lot of input from customers
on the compilation time issue, and it is true that for a few of them, 
the increased compilation time for GCC 3 over GCC 2, which is as much
as a factor of 2 in some cases is definitely significant.

We also have a couple of cases where the memory requirements 
skyrocketed, but these were clearly bugs, and we are working on
fixing the bug reports (as Eric knows :-)

Yes, there is a problem, but it does not help for people to yell 
catastrophe when it is nowhere *near* that.

Note that for other customers, the increased code quality from GCC 3 is
highly significant, and easily worth any increase in compilation time.

Re: gcc 3.5 integration branch proposal

[Eric Christopher]

> Let's face it: from the user viewpoint (all is in the viewpoint :-), during 
> the past few years, GCC has exchanged a reasonably good code quality coupled 
> with a good compilation speed for a slightly better code quality and a 
> catastrophic compilation speed.  Maybe this indicates that there is 
> something wrong in the development process.

i suppose it depends on the testcase (as we've seen in this thread
enough) as to whether the word "catastrophic" really applies here. And
perhaps the improvement in code quality indicates that there is
something right in the development process.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: gcc 3.5 integration branch proposal

[Eric Botcazou]

> My goodness, I would not even *consider* asking a professional developer
> (someone whose time is worth in the region of $1000 a day to a typical
> company) to use this low end machine. So we sure have totally different
> perspectives.

Sorry, I was imprecise.  I wanted to say that, from your viewpoint as a 
professional developer based in the US, this is certainly "a pretty 
reasonable machine at a very reasonable price".

> A home machine that costs $400 seems to me to be a reasonable definition
> of reasonable hardware. Note that we are not saying that gcc won't work
> at all on slower smaller machines, just that we expect relatively poor
> performance on such machines. If your valuation of your time is that you
> would rather put up with this poor performance than spend the $400
> that's certainly of course quite reasonable.

Again, I think this is a somewhat biased reasoning.  But I understand your 
viewpoint.

> Note that I did not say *only* by professionals, but to distort the
> project to say that all code must compile efficiently on machines that
> are three years old seems a mistake to me. Furthermore I think it will
> be counterproductive in improving peformance, since it is an unrealistic
> requirement.

Let's face it: from the user viewpoint (all is in the viewpoint :-), during 
the past few years, GCC has exchanged a reasonably good code quality coupled 
with a good compilation speed for a slightly better code quality and a 
catastrophic compilation speed.  Maybe this indicates that there is 
something wrong in the development process.

-- 
Eric Botcazou

Re: gcc 3.5 integration branch proposal

[Dale Johannesen]

On Jan 18, 2004, at 5:44 PM, Gabriel Dos Reis wrote:
> espie@quatramaran.ens.fr (Marc Espie) writes:
>
> | I do see the benefits, sure (I love the new preprocessor, except for 
> the
> | -traditional bug, and I really need a standard C++ compiler), but 
> updating
> | from 2.8.1 to 2.95 slowed our compiles by ~30%, and the on-going 
> 2.95 to
> | 3.3.2 update is slowing them by 30% more.    Heck, we do have
> | architectures that are NOT going to switch because the compile are
> | really too slow now.   There's even some chance only sparc64 will 
> switch
> | because 2.95 was completely crap on sparc64 (understandably so).
>
> We should probably require developers to use slow machines with small
> rams.  Semi ;-)

I know of 3 companies that tried this strategy at some point, on the 
theory that
turnaround time on minimal machines was important.
All 3 of them relented when they saw how unproductive their developers 
were.

Re: gcc 3.5 integration branch proposal

[Diego Novillo]

On Mon, 2004-01-19 at 14:15, Marc Espie wrote:

> That's a complete disaster.
>
Marc,

Please create a bugzilla report with the appropriate .i/.ii files.  This
mail thread will have been forgotten by next week.  The bugzilla report
will continue to remind us how bad things are until we fix it.



Thanks.  Diego.

Re: gcc 3.5 integration branch proposal

[Robert Dewar]

Eric Botcazou wrote:

>>That's a pretty reasonable machine at a very reasonable price.

> For a professional developer based in the US, certainly.  I'm not sure GCC 
> should primarily target such a population though.

My goodness, I would not even *consider* asking a professional developer
(someone whose time is worth in the region of $1000 a day to a typical
company) to use this low end machine. So we sure have totally different
perspectives.

The point is that you have to decide on some reasonable benchmark. To
use as the benchmark a machine bought three years ago for far more than
$400 does not seem realistic to me.

A home machine that costs $400 seems to me to be a reasonable definition 
of reasonable hardware. Note that we are not saying that gcc won't work
at all on slower smaller machines, just that we expect relatively poor
performance on such machines. If your valuation of your time is that you 
would rather put up with this poor performance than spend the $400 
that's certainly of course quite reasonable.

At some point you have to make a clear decision of whether you think of
gcc as a hobbyists tool for people who cannot afford any kind of 
reasonable hardware (remember that these days text books cost $100)
or whether it is a serious development tool usable by professionals.
Note that I did not say *only* by professionals, but to distort the
project to say that all code must compile efficiently on machines that 
are three years old seems a mistake to me. Furthermore I think it will
be counterproductive in improving peformance, since it is an unrealistic
requirement.

The idea here is to set a floor for machine performance for which we
consider that the compiler should have good performance. As I said in
my earlier note, the idea is that, at least till we update the baseline,
we do not say to people, get a faster/bigger machine. Instead we 
consider it something that needs fixing.

You might like gcc to give good performance with a three year old 
machine (that translates to approximately a 400MHz Pentium 3 with
32-64 megs of memory), but realistically I don't think this is going
to happen.

Note by the way that the pricing here was for a premium machine brand 
new from a premium vendor. If you want to rummage around the second hand 
market, or build yourself, you can obviously undercut this price (which
annoyingly for example includes the cost of Windows XP)

Re: gcc 3.5 integration branch proposal

[Eric Botcazou]

> Here is a suggestion:
>
> For $399 you can buy from Dell a brand new Dimension 2400 with a 2.4GHz
> Celeron, 400MHz front bus, 256 meg of memory, 40GB disk, 17" monitor,
> and 48x CD-RW/DVD-ROM combo drive.

I have always been amazed by the reasonings starting with "you can buy".  Why 
in the first place should you buy a brand new computer to do anything?  Why 
can't the typical 2-3 years old model be sufficient?

> That's a pretty reasonable machine at a very reasonable price.

For a professional developer based in the US, certainly.  I'm not sure GCC 
should primarily target such a population though.

-- 
Eric Botcazou

Re: gcc 3.5 integration branch proposal

[Jan Hubicka]

> On Mon, Jan 19, 2004 at 02:35:01PM +0100, Jan Hubicka wrote:
> > > On Sun, Jan 18, 2004 at 10:49:30PM -0500, David Edelsohn wrote:
> > > 
> > > > 	Did you build head configured with --disable-checking?
> > > 
> > > Rebuilt with --disable-checking, and double-checked the options. There
> > > was a bug that meant I was not -O2 in both cases.
> > > 
> > > Now, the actual options are 
> > > -Wall -Wstrict-prototypes -Wmissing-prototypes
> > > -Wno-uninitialized -Wno-format -Wno-main  -fno-builtin-printf
> > > -fno-builtin-log -fno-builtin-malloc -O2 -fno-strict-aliasing
> > > in both cases.
> > > 
> > > And it's still a bit slower:
> > > 
> > > gcc 3.3.2:
> > >   527.98s real   421.02s user    30.36s system
> > > 
> > > gcc -head  with --disable-checking:
> > >   544.91s real   439.52s user    30.27s system
> > > 
> > > 
> > > Okay, the slow-down is not as marked as with --enable-checking, but it
> > > still does exist: 4% is something.
> > 
> > You may consider using profiledbootstrap.  It makes bootstrap slower,
> > but it pays back in compilation time later.
> > 2 hours of whole build may already make it pay back.  In fact I would be
> > extremly curious about that.
> 
> Yep, profiledbootstrap is very, very slow, but the results are a little
> encouraging:
> 
>   515.03s real   389.54s user    30.42s system
> 
> So, it is slightly faster than 3.3.2...
> 
> I'll try doing some profiling for you guys, and building a complete archive
> that you can experiment with.
> 
> Now, for the killer question: assuming the OpenBSD project, at some point,
> moves to a recent gcc, we might want to have profile-directed compilation,
> but we definitely can't afford to run a full profiledbootstrap each time.
> 
> Is the format of profile information such that, say, it could be stored
> in arch-dependent directories, and then used for the compilation ?

No, actually the format is specific to even compiler settings.
This is because the profile can be read back to the compiler and can not
be addressed before tree-SSA is accepted.

It is however possible to make profledbootstrap faster with some effort.
At the moment we build all target libraries with profiling that has
relatively huge overhead especially for libjava.   We can try to put
together smaller testsuite, as the size of train set is usually not
important.

My experience is that C frontend works well when profilebootstrapped
only for C language where train run happens only for libgcc that is very
small and specific piece of code, so I would assume that simple tests
would be enough.

My original implementation of profiledbootstrap were mostly to test the
feature and thus I preferred when it is executed heavilly (doing so
motivated many optimization to the profiling mechanizm itself), but
perhaps it is good idea to revisit it.

It makes three stages - stage1 and stage1 is used to build both the
compiler used to produce feedback and the compiler to using the
feedback.  This shall not be much slower than usual 3 stage bootstrap
then.  Only disadvantage is that feedback stage (equivalent of stage3)
is built with non-optimizer stage1 compiler.

If frontend maintainers propose some smaller train runs, we can try to
put together this plan.
> 
> I'm asking this, because I had to kill one profiledbootstrap, and when
> I tried to resume it, it didn't work and told me I had used the wrong
> options.

This is not supposed to happen as long as you didn't changed your tree.
I sometimes re-do make profilebootstrap after stopping it by ctrl+c and
it seems to work, so I would be interested knowing more details if you
run into this problem again.

Honza

Re: gcc 3.5 integration branch proposal

[Marc Espie]

Completing the array:
gcc 3.3.2:
  527.98s real   421.02s user    30.36s system

gcc -head  with --disable-checking:
  544.91s real   439.52s user    30.27s system

gcc -head  with --disable-checking and profiled bootstrap
  515.03s real   389.54s user    30.42s system

gcc 2.95.3:
  349.10s real   244.46s user    23.40s system


Whichever way you look at it, it means that any of those recent gcc
are about 50% slower than gcc 2.95.3.

This is even worse than the feeling I had about it.

That's a complete disaster.

Re: gcc 3.5 integration branch proposal

[Marc Espie]

On Mon, Jan 19, 2004 at 02:35:01PM +0100, Jan Hubicka wrote:
> > On Sun, Jan 18, 2004 at 10:49:30PM -0500, David Edelsohn wrote:
> > 
> > > 	Did you build head configured with --disable-checking?
> > 
> > Rebuilt with --disable-checking, and double-checked the options. There
> > was a bug that meant I was not -O2 in both cases.
> > 
> > Now, the actual options are 
> > -Wall -Wstrict-prototypes -Wmissing-prototypes
> > -Wno-uninitialized -Wno-format -Wno-main  -fno-builtin-printf
> > -fno-builtin-log -fno-builtin-malloc -O2 -fno-strict-aliasing
> > in both cases.
> > 
> > And it's still a bit slower:
> > 
> > gcc 3.3.2:
> >   527.98s real   421.02s user    30.36s system
> > 
> > gcc -head  with --disable-checking:
> >   544.91s real   439.52s user    30.27s system
> > 
> > 
> > Okay, the slow-down is not as marked as with --enable-checking, but it
> > still does exist: 4% is something.
> 
> You may consider using profiledbootstrap.  It makes bootstrap slower,
> but it pays back in compilation time later.
> 2 hours of whole build may already make it pay back.  In fact I would be
> extremly curious about that.

Yep, profiledbootstrap is very, very slow, but the results are a little
encouraging:

  515.03s real   389.54s user    30.42s system

So, it is slightly faster than 3.3.2...

I'll try doing some profiling for you guys, and building a complete archive
that you can experiment with.

Now, for the killer question: assuming the OpenBSD project, at some point,
moves to a recent gcc, we might want to have profile-directed compilation,
but we definitely can't afford to run a full profiledbootstrap each time.

Is the format of profile information such that, say, it could be stored
in arch-dependent directories, and then used for the compilation ?

I'm asking this, because I had to kill one profiledbootstrap, and when
I tried to resume it, it didn't work and told me I had used the wrong
options.

Re: gcc 3.5 integration branch proposal

[Robert Dewar]

Scott Robert Ladd wrote:

> On the other hand, it is unwise for GCC to ignore compile speed, under
> the assumption that people can just buy a faster machine or more RAM.
> Not everyone is as fortunate as we...

But such generalities are not really useful unless quantified. Let's try
to define a machine which is reasonable as an expectation for anyone
doing serious software development. Reasonable in the sense that if 
someone is trying to use a less capable machine we won't get too upset
if the performance is poor.

Here is a suggestion:

For $399 you can buy from Dell a brand new Dimension 2400 with a 2.4GHz
Celeron, 400MHz front bus, 256 meg of memory, 40GB disk, 17" monitor,
and 48x CD-RW/DVD-ROM combo drive.

That's a pretty reasonable machine at a very reasonable price. I know 
it's a little ahead of what some people might have, but I think it is
still a reasonable benchmark machine. Basically the viewpoint is that
if you have such a machine, then until we upgrade the baseline, no one
is allowed to tell you that it's your fault for having too slow a 
machine that gcc performs poorly :-)

(it's a hundred bucks more to get a Pentium-4 with a 533Mhz bus, but I
think it's reasonable to go with the absolute low end here. After all
that machine is still a thousand times faster than the PC-1 and has a
thousand times more memory than the PC-1. For those who really want to
splurge, an extra $200 will get you a 17" flat panel, but somehow I
don't think that will help gcc performance much!)

Re: gcc 3.5 integration branch proposal

[Marc Espie]

On Mon, Jan 19, 2004 at 01:08:07PM -0500, Scott Robert Ladd wrote:
> This is what I meant by lauding GCC's "support for older hardware." I
> did quite a bit of cross-compiling for an embedded telephon application;
> I sure as heck don't expect my cell phone to run GCC!

One key point that I'd like to make, again, is that cross-compiling
kills old architectures, in terms of code quality.

I believe that the single most extensive test one can do is to build
a complete distribution on a system.

For quite a few cpu, there exists generalist machines, that can, in theory,
compile gcc, and then use it to compile an OS.

If you cross-compile everything, you will only run a select few
applications on that OS.

Experience has shown again and again that actually compiling large pieces
of software on a machine is one of the best all-purpose testcase one can 
wish for, between exercising the OS, running lots of small processes, and
dieing very quickly as soon as some faulty code happens, be it in the
compiler, the linker, the kernel, or in whatever piece such a complex software
architecture is composed of.

Remember that note about signal 11 on PCs, being attributable to faulty
memory ?   Do you think that it is a coincidence such signals were most
often seen while running a compilation, to the extent that an item had
to be added to the GCC FAQ, mentioning that it was faulty memory, and
likely not GCC's fault.

Re: gcc 3.5 integration branch proposal

[Scott Robert Ladd]

Robert Dewar wrote:
> The excellent support for cross-compilation on the other hand does seem
> a key advantage, and that is what makes it practical to target older
> machines.

This is what I meant by lauding GCC's "support for older hardware." I
did quite a bit of cross-compiling for an embedded telephon application;
I sure as heck don't expect my cell phone to run GCC!

On the other hand, it is unwise for GCC to ignore compile speed, under
the assumption that people can just buy a faster machine or more RAM.
Not everyone is as fortunate as we...

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: gcc 3.5 integration branch proposal

[Scott Robert Ladd]

Robert Dewar wrote:
> The excellent support for cross-compilation on the other hand does seem
> a key advantage, and that is what makes it practical to target older
> machines.

This is what I meant by lauding GCC's "support for older hardware." I 
did quite a bit of cross-compiling for an embedded telephon application; 
I sure as heck don't expect my cell phone to run GCC!

On the other hand, it is unwise for GCC to ignore compile speed, under 
the assumption that people can just buy a faster machine or more RAM. 
Not everyone is as fortunate as we...

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: gcc 3.5 integration branch proposal

[Gabriel Dos Reis]

Robert Dewar <dewar@gnat.com> writes:

| That being said, it seems to me to undervalue time to be using a two
| year old machine and tolerating builds that slow when a modern notebook
| with a 3GHz processor and 800MHz front bus can be obtained for under
| $2000.

A key point is that not everyone can afford changing hardware every
one/two years for that price (assuming it is possible), and even if it
were financially possible, it may not be technically or pratically
desirable.  We have been through that discussion before.

| And one general comment here is that using such a notebook, I
| still find MANY things to be slow, and gcc is not the worst offender
| by any means (Mozilla's junk mail detection, while excellent, for
| example, consumes vast amounts of cycles and how Power Point manages
| to take as long as it does to come up is a mystery to me). I guess the
| software world has become really *expert* at making things take
| thousands of times longer than they should :-(

Software expertise has changed axes ;-)

-- Gaby

Re: gcc 3.5 integration branch proposal

[Jan Hubicka]

> On Sun, Jan 18, 2004 at 10:49:30PM -0500, David Edelsohn wrote:
> 
> > 	Did you build head configured with --disable-checking?
> 
> Rebuilt with --disable-checking, and double-checked the options. There
> was a bug that meant I was not -O2 in both cases.
> 
> Now, the actual options are 
> -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wno-uninitialized -Wno-format -Wno-main  -fno-builtin-printf
> -fno-builtin-log -fno-builtin-malloc -O2 -fno-strict-aliasing
> in both cases.
> 
> And it's still a bit slower:
> 
> gcc 3.3.2:
>   527.98s real   421.02s user    30.36s system
> 
> gcc -head  with --disable-checking:
>   544.91s real   439.52s user    30.27s system
> 
> 
> Okay, the slow-down is not as marked as with --enable-checking, but it
> still does exist: 4% is something.
> 
> Basically, the code there is just an OpenBSD kernel. It won't fly as a
> testcase unless you have an OpenBSD system available.
> 
> It's just plain old C.  Nothing really fancy about it.
> 
> So, the compiler is not getting faster.
> 
> To give you some scope, again. A similar bulk of code used to compile in
> 3 hours on a 68040.  This 4% translates to an extra 7 minutes.

Since you apparently do have access to 68040 machine easilly, would be
possible for you to post some comparsion of the speed relative to gcc
2.95?
One of major changes of post 3.0 GCCs is the new x86 backend that has
many advantages for modern CPUs (support for scheduling, SSE, x86-64)
but is whole a lot more complex and memory houngry than the old has
been.  I would be very curious how the numbers look like on the machine
where backend didn't changed much.
The profiles would be very welcome too!
I do have one 68040 myself, but it is 120Km away right now :)

Honza
> 
> A make build on such a machine takes about two days. This 4% translates to
> 2 hours more.
> 
> I'll try doing some profiling in the near future...

Re: gcc 3.5 integration branch proposal

[Robert Dewar]

Marc Espie wrote:

> Another data point: I don't think I have an especially slow development
> machine (PIII 1.2GHz), even though it's two years old, and yet the
> project I work with entails compilation times of over a day...

That is presumably a time and not space complaint (i.e. the day does not
come from virtual memory disk thrashing).

To me, a project that requires a compilation time of a day on a 1.2GHz
machine is indeed indicative of a non-functional compiler. I definitely
agree that this kind of performance should be considered to be a bug. My
direct interaction with gcc is most typically complete bootstraps of 
GNAT, which take about 10 minutes on my laptop, which seems slow but
acceptable. Dealing with a project where recompilation takes a day is
I agree well outside the acceptable range.

That being said, it seems to me to undervalue time to be using a two 
year old machine and tolerating builds that slow when a modern notebook
with a 3GHz processor and 800MHz front bus can be obtained for under
$2000. And one general comment here is that using such a notebook, I 
still find MANY things to be slow, and gcc is not the worst offender
by any means (Mozilla's junk mail detection, while excellent, for
example, consumes vast amounts of cycles and how Power Point manages
to take as long as it does to come up is a mystery to me). I guess the
software world has become really *expert* at making things take 
thousands of times longer than they should :-(

Re: gcc 3.5 integration branch proposal

[Robert Dewar]

Scott Robert Ladd wrote:

> Define a "lean-and-mean" build, perhaps focused on C, that reduces 
> system requirements and focuses on compilation speed. One of GCC's key 
> advantages is its support for "older" hardware.

I do not agree that it is a particular advantage (let alone a key 
advantage) for gcc to be able to be hosted on "older" hardware. It is
indeed valuable to be able to generate code for older hardware. 
Certainly for example, people are going to be using 68020 processors
in embedded applications for a long time, but I don't particularly
see it as useful to be able to run latest versions of GCC on old
68020 based macs.

The excellent support for cross-compilation on the other hand does seem
a key advantage, and that is what makes it practical to target older
machines.

Re: gcc 3.5 integration branch proposal

[Robert Dewar]

Gabriel Dos Reis wrote:

> I suggest you spend some time in the bugzilla database, triaging bugs
> and explaining people who say that the compiler segfaulted -- when
> compiling their programs, and you have determined that GCC was
> consuming  huge memory  -- that they are marginal. 
> Until then, I guess we're just going through an empty discussion. 

You are confusing apples and oranges.

What I was talking about here was increases in memory requirements
that mean that gcc does not operate well on outdated "small RAM"
machines so that there are programs which would once have compiled
OK on such machines and don't any longer.

It is of course a totally different matter if algorithms are introduced
which use absurd amounts of memory so that programs cannot even be
compiled on machines with a gigabyte of memory. There are most 
definitely such cases, and to me such cases are plain bugs. There is
really no excuse for a compiler requiring huge amounts of room. In fact
I don't really like the style of relying on virtual memory to guarantee
that huge data structures can be held in memory, but I am afraid we are
pretty much stuck with that.

It's somewhat the style in the C and C++ world to assume that each
individual compiled file should be small, and that it's not so terrible
if a compiler can't handle really large source files. I find this quite
unacceptable. For one thing, you can legitimately get huge files if they
are the output of code generators, and compilers should be able to 
handle such cases fine.

We certainly have bumped up against several cases in which gcc 
algorithms blew up horribly in space and time (the two usually go
together in these cases of serious performance bugs).

To put it concretely, it would not worry me if gcc could compile all 
sorts of giant programs comfortably in 256 megabytes, but was hopeless
on smaller machines. A machine with 256 megs is not what I would call
a "small RAM" machine.

Part of the trouble it seems to me with GCC is that there have never 
been any concrete performance requirements in terms of compile speed
and space requirements.

That's a matter of emphasis. In the case of Realia COBOL for instance,
compile speed was a primary functional requirement, and space was
constrained to 640 kilobytes by the hardware. We could still compile
million line files, and did so routinely to check that this worked fine
(on a PC1 at 5MHz, a million line file could take a couple of hours
to compile, but we made sure it did not get suddently worse than that).

Re: gcc 3.5 integration branch proposal

[Scott Robert Ladd]

Marc Espie wrote:
> On Mon, Jan 19, 2004 at 11:07:59AM -0500, Scott Robert Ladd wrote:
>>Define a "lean-and-mean" build, perhaps focused on C, that reduces 
>>system requirements and focuses on compilation speed. One of GCC's key 
>>advantages is its support for "older" hardware.
>            ^^
> 
> Nope, `used to be'.
> 
> Yes, that's past sense.
> 
> But older hardware is no longer really supported by GCC, between the
> large memory footprint and the huge compilation slowdown.
> 
I'm all in favor of aggressive optimization on modern hardware. I'm also 
concerned that the Microsoft attitude of "buy a faster computer" is 
infiltrating GCC's development. Nor is GCC alone; too many "free" 
software projects suffer a similar problem.

 > I believe that's a choice that has been made by several people.
 > There are compromises to be made, as always. And current GCC is going
 > toward aggressive optimizations on modern hardware.

I've had it beaten into my head (on this forum) that 
"free-as-in-liberty" software is driven by scratching itches and funding 
issues. "If it's important, someone will pay for it" is the mantra -- 
and older and smaller hardware does not attract development funds.

> Don't say it has `good support' for older hardware. The increased
> compilation times and memory footprint make that a complete lie.

I think you're being too harsh; I did not say "good support", I simply 
said "support."

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: gcc 3.5 integration branch proposal

[Jan Hubicka]

> Jan Hubicka wrote:
> > 
> > > Jan Hubicka wrote:
> > >
> > > >This is precisely what I intend to do now, yes.
> > > >I re-did your experiment on my notebook (Centrino, 256MB ram)
> > >
> > > It's useful to give the exact configuration, in particular the processor
> > > speed. Note that by the way Centrino does NOT designate a processor, but
> > > rather a system including specific wifi support, though it implies the
> > > Pentium-M. That's a very different core than the Pentium-4 or Pentium-4M
> > > so it is useful to repeat such measurements on the latter machines.
> > 
> > My CPU is Pentium-M 1.3Mhz with speedstep disabled, tought it seems to
> > me that only interesting about it is particular CPU core that is mostly
> > Pentium-3 and memory/CPU speed ratio that I unforutnately don't know
> > offhand.
> > 
> 
>   I've started work on tuning gcc to Pentium-M.  It is not a exactly
> Pentium 3 core.  Although it has constraints on insn issue analogous to
> Pentium-pro.  Also it looks like pentium-m has a multiplier from
> pentium-3 too.  Because the frequency processor is quite different from
> pentium4, the memory/CPU speed ratio is also different.

Actually I did other tests posted to the list earlier.  First was about
Gerald's C++ testcase that was done on 1.7Mhz Athlon XP 2100+ and other
was SPEC2000 runs 1.6Mhz Opteron.  Both were consistent with the results
I got there showing speedup relative to GCC 3.0 and 3.3 (hammer branch)
repsectivly.

So I believe that the particular chip has relatively small impact about
the numbers.

I can't access Pentium4 based system.

Honza
> 
> Vlad

Re: gcc 3.5 integration branch proposal

[Per Bothner]

Nick Burrett wrote:

> There's no harm in that.  I have a port of GCC 3.3.3 running on a 200MHz 
> StrongARM that takes over 6 minutes to compile the following:
> 
>    #include <iostream>
> 
>    int main (void)
>    {
>      std::cout << "Hello World" << std::endl;
>      return 0;
>    }
> 
> GCC 2.95.4 compiled the same application on the same hardware in around 
> 20-30 seconds.

You're comparing apples and oranges.  These are *not* the same
application, as the <iostream> headers are much more complicated.
This is due to requirements in the C++ standard.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: gcc 3.5 integration branch proposal

[Marc Espie]

On Mon, Jan 19, 2004 at 11:07:59AM -0500, Scott Robert Ladd wrote:
> Define a "lean-and-mean" build, perhaps focused on C, that reduces 
> system requirements and focuses on compilation speed. One of GCC's key 
> advantages is its support for "older" hardware.
             ^^

Nope, `used to be'.

Yes, that's past sense.

But older hardware is no longer really supported by GCC, between the
large memory footprint and the huge compilation slowdown.

I believe that's a choice that has been made by several people.
There are compromises to be made, as always. And current GCC is going
toward aggressive optimizations on modern hardware.

Don't say it has `good support' for older hardware. The increased
compilation times and memory footprint make that a complete lie.

I, for one, would love to get it back to `normal' behavior, while
keeping the aggressive optimization on newer machines.

Another data point: I don't think I have an especially slow development
machine (PIII 1.2GHz), even though it's two years old, and yet the
project I work with entails compilation times of over a day...

Re: gcc 3.5 integration branch proposal

[Scott Robert Ladd]

Gabriel Dos Reis wrote:
> I suggest you spend some time in the bugzilla database, triaging bugs
> and explaining people who say that the compiler segfaulted -- when
> compiling their programs, and you have determined that GCC was
> consuming  huge memory  -- that they are marginal. 
> Until then, I guess we're just going through an empty discussion. 

Well, people can tell me I'm nuttier than a fruitcake, but here's a wild 
suggestion:

Define a "lean-and-mean" build, perhaps focused on C, that reduces 
system requirements and focuses on compilation speed. One of GCC's key 
advantages is its support for "older" hardware.

Such an approach might go a long way toward satisfying the various 
constituencies who want faster compiles on limited systems.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: gcc 3.5 integration branch proposal

[Gabriel Dos Reis]

Robert Dewar <dewar@gnat.com> writes:

| So in the quote above, I would agree with the "slow machines", but
| not the "small RAM". I think it is just fine to trade off larger memory
| requirements against better code. Given a world in which people are used
| to the idea of a PC where 128 megabytes is marginal, using substantially
| more memory is not an issue.

I suggest you spend some time in the bugzilla database, triaging bugs
and explaining people who say that the compiler segfaulted -- when
compiling their programs, and you have determined that GCC was
consuming  huge memory  -- that they are marginal. 
Until then, I guess we're just going through an empty discussion. 

-- Gaby

Re: gcc 3.5 integration branch proposal

[Vladimir Makarov]

Jan Hubicka wrote:
> 
> > Jan Hubicka wrote:
> >
> > >This is precisely what I intend to do now, yes.
> > >I re-did your experiment on my notebook (Centrino, 256MB ram)
> >
> > It's useful to give the exact configuration, in particular the processor
> > speed. Note that by the way Centrino does NOT designate a processor, but
> > rather a system including specific wifi support, though it implies the
> > Pentium-M. That's a very different core than the Pentium-4 or Pentium-4M
> > so it is useful to repeat such measurements on the latter machines.
> 
> My CPU is Pentium-M 1.3Mhz with speedstep disabled, tought it seems to
> me that only interesting about it is particular CPU core that is mostly
> Pentium-3 and memory/CPU speed ratio that I unforutnately don't know
> offhand.
> 

  I've started work on tuning gcc to Pentium-M.  It is not a exactly
Pentium 3 core.  Although it has constraints on insn issue analogous to
Pentium-pro.  Also it looks like pentium-m has a multiplier from
pentium-3 too.  Because the frequency processor is quite different from
pentium4, the memory/CPU speed ratio is also different.

Vlad

Re: gcc 3.5 integration branch proposal

[Jan Hubicka]

> Jan Hubicka wrote:
> 
> >This is precisely what I intend to do now, yes.
> >I re-did your experiment on my notebook (Centrino, 256MB ram)
> 
> It's useful to give the exact configuration, in particular the processor
> speed. Note that by the way Centrino does NOT designate a processor, but
> rather a system including specific wifi support, though it implies the
> Pentium-M. That's a very different core than the Pentium-4 or Pentium-4M
> so it is useful to repeat such measurements on the latter machines.

My CPU is Pentium-M 1.3Mhz with speedstep disabled, tought it seems to
me that only interesting about it is particular CPU core that is mostly
Pentium-3 and memory/CPU speed ratio that I unforutnately don't know
offhand.

Honza
> 
> 

Re: gcc 3.5 integration branch proposal

[Robert Dewar]

Jan Hubicka wrote:

> This is precisely what I intend to do now, yes.
> I re-did your experiment on my notebook (Centrino, 256MB ram)

It's useful to give the exact configuration, in particular the processor
speed. Note that by the way Centrino does NOT designate a processor, but
rather a system including specific wifi support, though it implies the
Pentium-M. That's a very different core than the Pentium-4 or Pentium-4M
so it is useful to repeat such measurements on the latter machines.

Re: gcc 3.5 integration branch proposal

[Robert Dewar]

Nick Burrett wrote:

>> We should probably require developers to use slow machines with small
>> rams.  Semi ;-)
> 
> 
> There's no harm in that.  I have a port of GCC 3.3.3 running on a 200MHz 
> StrongARM that takes over 6 minutes to compile the following:

I would distinguish between speed and space here. It really is quite
reasonable for gcc to require more memory as it goes along, since one
can indeed reasonably assume that modern developers machines have
reasonable memory. That's a technology change that is reasonable to
take advantage of.

The original Realia COBOL ran on a 4.77MHz PC1 and compiled about
10,000 lines/minute on that machine in 640K bytes (the compiler was
about 100K bytes, with the remaining 540K used for file caching. That
was for a full featured COBOL compiler that could compile programs of
any size at all with no non-linear behavior. The code it generated was
good but not great (although at the time, in the 80's it was the best
compiler for any language around on the PC in terms of generated code).

Now these days, the raw speed of the compiler is still significant,
because people compile HUGE COBOL programs and anyway it is always
welcome to have rapid response on compiling a big program. In the
case of the compiler itself, written in COBOL, about 100,000 lines
it was always most welcome on a fast 386 to be able to bootstrap
in a couple of minutes. I don't know how fast that compiler is on
a modern PC, I assume a bootstrap takes seconds these days.

But the fact that the compiler can operate in very small memory is
simply not interesting today.

So in the quote above, I would agree with the "slow machines", but
not the "small RAM". I think it is just fine to trade off larger memory
requirements against better code. Given a world in which people are used
to the idea of a PC where 128 megabytes is marginal, using substantially
more memory is not an issue.

But trading off compilation *speed* against better code quality is
more dubious. Yes, machines get faster, but that's also an argument
that says that getting a few percent more efficiency from generated
code is no longer so critical.

You are far more likely to have someone compiling a million line
program where 20% performance is not an issue, but compilation
times of hours is a real issue that impedes development.

It would be interesting to have a set of benchmarks showing the compile
time performance of GCC over a period of years, and comparing that with
other compilers.

Robert Dewar

Re: gcc 3.5 integration branch proposal

[Jan Hubicka]

> On Sun, Jan 18, 2004 at 10:49:30PM -0500, David Edelsohn wrote:
> 
> > 	Did you build head configured with --disable-checking?
> 
> Rebuilt with --disable-checking, and double-checked the options. There
> was a bug that meant I was not -O2 in both cases.
> 
> Now, the actual options are 
> -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wno-uninitialized -Wno-format -Wno-main  -fno-builtin-printf
> -fno-builtin-log -fno-builtin-malloc -O2 -fno-strict-aliasing
> in both cases.
> 
> And it's still a bit slower:
> 
> gcc 3.3.2:
>   527.98s real   421.02s user    30.36s system
> 
> gcc -head  with --disable-checking:
>   544.91s real   439.52s user    30.27s system
> 
> 
> Okay, the slow-down is not as marked as with --enable-checking, but it
> still does exist: 4% is something.
> 
> Basically, the code there is just an OpenBSD kernel. It won't fly as a
> testcase unless you have an OpenBSD system available.
> 
> It's just plain old C.  Nothing really fancy about it.
> 
> So, the compiler is not getting faster.
> 
> To give you some scope, again. A similar bulk of code used to compile in
> 3 hours on a 68040.  This 4% translates to an extra 7 minutes.

Also if compilation speed is your major concern on older architectures,
you may consider disabling GCSE that consume about 6% of compilation
time at about 1-2% code quality improvements or even consider using -O1
everywhere, that one has generally better code quality/compilation time
tradeoffs.

Honza
> 
> A make build on such a machine takes about two days. This 4% translates to
> 2 hours more.
> 
> I'll try doing some profiling in the near future...

Re: gcc 3.5 integration branch proposal

[Diego Novillo]

On Mon, 2004-01-19 at 08:28, Marc Espie wrote:

> Basically, the code there is just an OpenBSD kernel. It won't fly as a
> testcase unless you have an OpenBSD system available.
> 
Since it's a compile-time test, perhaps you could do a run with
-save-temps and provide a tarball with the .i files?  We have such a
collection out of a GCC bootstrap.


Thanks.  Diego.

Re: gcc 3.5 integration branch proposal

[Jan Hubicka]

> On Sun, Jan 18, 2004 at 10:49:30PM -0500, David Edelsohn wrote:
> 
> > 	Did you build head configured with --disable-checking?
> 
> Rebuilt with --disable-checking, and double-checked the options. There
> was a bug that meant I was not -O2 in both cases.
> 
> Now, the actual options are 
> -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wno-uninitialized -Wno-format -Wno-main  -fno-builtin-printf
> -fno-builtin-log -fno-builtin-malloc -O2 -fno-strict-aliasing
> in both cases.
> 
> And it's still a bit slower:
> 
> gcc 3.3.2:
>   527.98s real   421.02s user    30.36s system
> 
> gcc -head  with --disable-checking:
>   544.91s real   439.52s user    30.27s system
> 
> 
> Okay, the slow-down is not as marked as with --enable-checking, but it
> still does exist: 4% is something.

You may consider using profiledbootstrap.  It makes bootstrap slower,
but it pays back in compilation time later.
2 hours of whole build may already make it pay back.  In fact I would be
extremly curious about that.

Honza

Re: gcc 3.5 integration branch proposal

[Marc Espie]

On Sun, Jan 18, 2004 at 10:49:30PM -0500, David Edelsohn wrote:

> 	Did you build head configured with --disable-checking?

Rebuilt with --disable-checking, and double-checked the options. There
was a bug that meant I was not -O2 in both cases.

Now, the actual options are 
-Wall -Wstrict-prototypes -Wmissing-prototypes
-Wno-uninitialized -Wno-format -Wno-main  -fno-builtin-printf
-fno-builtin-log -fno-builtin-malloc -O2 -fno-strict-aliasing
in both cases.

And it's still a bit slower:

gcc 3.3.2:
  527.98s real   421.02s user    30.36s system

gcc -head  with --disable-checking:
  544.91s real   439.52s user    30.27s system


Okay, the slow-down is not as marked as with --enable-checking, but it
still does exist: 4% is something.

Basically, the code there is just an OpenBSD kernel. It won't fly as a
testcase unless you have an OpenBSD system available.

It's just plain old C.  Nothing really fancy about it.

So, the compiler is not getting faster.

To give you some scope, again. A similar bulk of code used to compile in
3 hours on a 68040.  This 4% translates to an extra 7 minutes.

A make build on such a machine takes about two days. This 4% translates to
2 hours more.

I'll try doing some profiling in the near future...

Re: gcc 3.5 integration branch proposal

[Jan Hubicka]

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

> > In fact, I finally got around to building gcc-head, and comparing it
> > to gcc 3.3.2.
> > 
> > To say that the results are disappointing would be an understatement:
> > 
> > Time for a kernel compile, gcc 3.3.2:
> >   276.63s real   193.01s user    26.86s system
> > with gcc-head:
> >   341.31s real   213.25s user    27.87s system
> > 
> > Exact same options, basically -O2.
> > 
> > Now, tell me again that GCC is getting faster...
> 
> This is precisely what I intend to do now, yes.
> I re-did your experiment on my notebook (Centrino, 256MB ram) with Linux
> kernel 2.6.1.  I disabled checking and profiledbootstrapped mainline, 
> and compared it to current disabled checking bootstrapped 3.2 branch.
> 
> For 3.4 I get:
> real    6m44.513s
> user    6m13.057s
> sys     0m23.915s
> 
> For 3.2 I get:
> real    7m53.661s
> user    7m19.730s
> sys     0m24.206s
> 

For 3.3 I get:
real    7m50.506s
user    7m6.577s
sys     0m29.863s

So it appears that your problem may be just trivial bug either in GCC or
testing.  If you provide more details, I will look into it.

Honza

[-- Attachment #2: 3.3 --]
[-- Type: text/plain, Size: 45083 bytes --]

CPU: CPU with timer interrupt, speed 1299.43 MHz (estimated)
Profiling through timer interrupt
vma      samples  %           app name                 symbol name
0007ae60 25079     6.0144     libc.so.6                memset
082ace80 15729     3.7721     cc1                      htab_find_slot_with_hash
080496f0 14222     3.4107     cc1                      yyparse
08235d70 9917      2.3783     cc1                      ggc_alloc
08229340 8771      2.1034     cc1                      walk_tree
08203c40 6593      1.5811     cc1                      for_each_rtx
080899d0 5853      1.4036     cc1                      ht_lookup
080a7b50 5432      1.3027     cc1                      cse_insn
00074fd0 4612      1.1060     libc.so.6                _int_malloc
0807e380 4360      1.0456     cc1                      _cpp_lex_direct
082031b0 3571      0.8564     cc1                      side_effects_p
00000000 3463      0.8305     as                       (no symbols)
00077f20 3378      0.8101     libc.so.6                strcmp
000793f0 3056      0.7329     libc.so.6                strlen
081e3da0 3008      0.7214     cc1                      reg_scan_mark_refs
080ef850 2960      0.7099     cc1                      mark_set_1
081da2a0 2914      0.6988     cc1                      constrain_operands
080ee630 2810      0.6739     cc1                      propagate_one_insn
0808bd30 2752      0.6600     cc1                      canon_rtx
08057a00 2726      0.6537     cc1                      grokdeclarator
081e21a0 2645      0.6343     cc1                      record_reg_classes
08056560 2581      0.6190     cc1                      lookup_tag
080a0e30 2481      0.5950     cc1                      rtx_cost
0807d9a0 2402      0.5760     cc1                      parse_identifier
080a53a0 2346      0.5626     cc1                      fold_rtx
080a4800 2297      0.5509     cc1                      canon_reg
08220f10 2237      0.5365     cc1                      make_node
080f9140 2196      0.5266     cc1                      fold
080898e0 2146      0.5146     cc1                      calc_hash
08202510 2146      0.5146     cc1                      note_stores
08202b20 2144      0.5142     cc1                      find_reg_note
00000000 2139      0.5130     gzip                     (no symbols)
08198da0 2107      0.5053     cc1                      mark_jump_label
080abfd0 2043      0.4899     cc1                      count_reg_usage
0807d690 2038      0.4887     cc1                      skip_block_comment
080811c0 2024      0.4854     cc1                      cpp_get_token
081d2d40 1969      0.4722     cc1                      do_add
0808e0a0 1964      0.4710     cc1                      init_alias_analysis
082ad0c0 1956      0.4691     cc1                      htab_find_slot
081e8e70 1876      0.4499     cc1                      find_reloads
080f0eb0 1838      0.4408     cc1                      force_fit_type
080a2ee0 1823      0.4372     cc1                      invalidate
080f03a0 1773      0.4252     cc1                      mark_used_regs
080f2210 1713      0.4108     cc1                      int_const_binop
080dff10 1655      0.3969     cc1                      expand_expr
081e0330 1612      0.3866     cc1                      init_reg_sets_1
080a38e0 1597      0.3830     cc1                      canon_hash
080a25f0 1537      0.3686     cc1                      insert
081d30a0 1459      0.3499     cc1                      do_multiply
0007b5e0 1456      0.3492     libc.so.6                memcpy
08052ca0 1391      0.3336     cc1                      c_lex
080a1660 1386      0.3324     cc1                      get_cse_reg_info
00000000 1336      0.3204     make                     (no symbols)
0808ea90 1325      0.3178     cc1                      bitmap_bit_p
0807e1d0 1310      0.3142     cc1                      _cpp_lex_token
082288e0 1293      0.3101     cc1                      find_builtin_longjmp_call_1
082003b0 1270      0.3046     cc1                      rtx_equal_p
08201e50 1267      0.3038     cc1                      refers_to_regno_p
081d9ba0 1257      0.3014     cc1                      extract_insn
080489d0 1256      0.3012     fixdep                   parse_config_file
08220e40 1248      0.2993     cc1                      tree_size
081e41b0 1220      0.2926     cc1                      reg_class_subset_p
08207d10 1216      0.2916     cc1                      simplify_binary_operation
081d2c70 1207      0.2895     cc1                      normalize
0823bbd0 1192      0.2859     cc1                      ix86_decompose_address
081d8450 1180      0.2830     cc1                      general_operand
0823c310 1155      0.2770     cc1                      legitimate_address_p
080f2ef0 1144      0.2744     cc1                      size_htab_eq
082ad6c0 1131      0.2712     cc1                      splay_tree_splay_helper
08070210 1127      0.2703     cc1                      statement_code_p
080c4f90 1102      0.2643     cc1                      copy_rtx_if_shared
080f10d0 1082      0.2595     cc1                      mul_double
081fdfb0 1055      0.2530     cc1                      reload_cse_simplify_operands
082acb50 1052      0.2523     cc1                      hash_pointer
080a3e50 1037      0.2487     cc1                      exp_equiv_p
08219e30 1036      0.2485     cc1                      timevar_pop
0808e980 1004      0.2408     cc1                      bitmap_set_bit
000755e0 973       0.2333     libc.so.6                _int_free
00000000 956       0.2293     bash                     (no symbols)
000742d0 945       0.2266     libc.so.6                __cfree
080a1b60 945       0.2266     cc1                      mention_regs
0807d850 928       0.2225     cc1                      skip_whitespace
080f0010 927       0.2223     cc1                      mark_used_reg
08252280 909       0.2180     cc1                      find_basic_blocks_1
082ad1c0 904       0.2168     cc1                      htab_traverse
080a0c70 896       0.2149     cc1                      approx_reg_cost_1
080f2f70 894       0.2144     cc1                      size_int_type_wide
081d2920 882       0.2115     cc1                      sticky_rshift_significand
08203df0 880       0.2110     cc1                      commutative_operand_precedence
080f3060 878       0.2106     cc1                      size_binop
080ad4d0 869       0.2084     cc1                      cselib_lookup
00007600 866       0.2077     ld-2.3.2.so              do_lookup_versioned
00075800 861       0.2065     libc.so.6                malloc_consolidate
00074980 835       0.2002     libc.so.6                __calloc
081d2b50 835       0.2002     cc1                      lshift_significand
08221090 835       0.2002     cc1                      copy_node
0808ec70 834       0.2000     cc1                      bitmap_operation
08219d50 829       0.1988     cc1                      timevar_push
080f2eb0 818       0.1962     cc1                      size_htab_hash
00074100 807       0.1935     libc.so.6                __malloc
0804e890 796       0.1909     cc1                      yylex
0808bb00 790       0.1895     cc1                      record_set
0807d800 786       0.1885     cc1                      adjust_column
0822efd0 766       0.1837     cc1                      decode_reg_name
0808c110 763       0.1830     cc1                      find_base_term
08200190 763       0.1830     cc1                      copy_rtx
082226f0 761       0.1825     cc1                      first_rtl_op
08228180 724       0.1736     cc1                      copy_body_r
082519f0 724       0.1736     cc1                      control_flow_insn_p
08202190 721       0.1729     cc1                      reg_overlap_mentioned_p
080c5d40 707       0.1696     cc1                      add_insn
0804ea00 705       0.1691     cc1                      _yylex
08293d30 684       0.1640     cc1                      insn_extract
08052110 683       0.1638     cc1                      decl_attributes
080490b0 678       0.1626     cc1                      anonymous symbol from section .plt
00077d50 669       0.1604     libc.so.6                index
0808be10 641       0.1537     cc1                      rtx_equal_for_memref_p
00047c40 638       0.1530     libc.so.6                _IO_vfprintf_internal
080c37a0 631       0.1513     cc1                      set_mem_attributes_minus_bitpos
080c5160 626       0.1501     cc1                      reset_used_flags
082030f0 623       0.1494     cc1                      volatile_refs_p
080abb70 614       0.1472     cc1                      cse_basic_block
080ad760 614       0.1472     cc1                      cselib_invalidate_regno
080a3630 609       0.1460     cc1                      invalidate_for_call
08228b30 608       0.1458     cc1                      expand_call_inline
0808c5f0 602       0.1444     cc1                      memrefs_conflict_p
081d7310 594       0.1425     cc1                      div_significands
080a23d0 591       0.1417     cc1                      lookup
08251950 591       0.1417     cc1                      inside_basic_block_p
080ab510 590       0.1415     cc1                      cse_end_of_basic_block
082298d0 589       0.1413     cc1                      copy_tree_r
0804e660 585       0.1403     cc1                      yylexname
00011410 583       0.1398     ld-2.3.2.so              strcmp
0002ba00 579       0.1389     libc.so.6                __GI_getenv
082acb60 576       0.1381     cc1                      eq_pointer
000095d0 569       0.1365     ld-2.3.2.so              _dl_relocate_object_internal
080ada90 564       0.1353     cc1                      cselib_invalidate_mem_1
082239b0 563       0.1350     cc1                      is_attribute_p
082019e0 553       0.1326     cc1                      single_set_2
082aad70 553       0.1326     cc1                      splay
080f0db0 552       0.1324     cc1                      reg_set_to_hard_reg_set
080ac400 546       0.1309     cc1                      delete_trivially_dead_insns
080487f0 546       0.1309     fixdep                   is_defined_config
08055930 541       0.1297     cc1                      pushdecl
0807d3f0 541       0.1297     cc1                      handle_newline
0825cb40 540       0.1295     cc1                      subst
08254f10 535       0.1283     cc1                      try_optimize_cfg
081d9e20 533       0.1278     cc1                      preprocess_constraints
080ace20 532       0.1276     cc1                      hash_rtx
082a1310 527       0.1264     cc1                      sched_analyze_insn
00015b8f 522       0.1252     libc.so.6                __i686.get_pc_thunk.bx
08201b50 516       0.1237     cc1                      set_noop_p
08221520 515       0.1235     cc1                      integer_zerop
08223620 506       0.1213     cc1                      build1
080abf70 505       0.1211     cc1                      check_for_label_ref
082659f0 505       0.1211     cc1                      nonzero_bits1
0824dbf0 490       0.1175     cc1                      ix86_memory_move_cost
081e44a0 488       0.1170     cc1                      invalid_mode_change_p
080c6ec0 484       0.1161     cc1                      emit_note
08225600 483       0.1158     cc1                      variably_modified_type_p
08222220 482       0.1156     cc1                      tree_cons
080d15a0 477       0.1144     cc1                      synth_mult
0820faa0 476       0.1142     cc1                      expand_asm_operands
0002dc10 475       0.1139     libc.so.6                __GI___strtoul_internal
082acd90 472       0.1132     cc1                      htab_find_with_hash
08200150 471       0.1130     cc1                      rtx_alloc
08106420 467       0.1120     cc1                      assign_parms
080a4a10 453       0.1086     cc1                      find_best_addr
0816dbb0 451       0.1082     cc1                      recog_17
08223ca0 451       0.1082     cc1                      get_qualified_type
080eef30 445       0.1067     cc1                      propagate_block
08079f30 444       0.1065     cc1                      expand_stmt
0805f7c0 438       0.1050     cc1                      build_binary_op
082098c0 438       0.1050     cc1                      simplify_plus_minus
08224420 438       0.1050     cc1                      host_integerp
082220d0 433       0.1038     cc1                      list_length
08251ae0 432       0.1036     cc1                      count_basic_blocks
082534e0 426       0.1022     cc1                      try_forward_edges
080ef6c0 425       0.1019     cc1                      mark_set_regs
08197a40 423       0.1014     cc1                      init_label_info
0823c000 421       0.1010     cc1                      ix86_find_base_term
081e4210 419       0.1005     cc1                      reg_classes_intersect_p
000073c0 415       0.0995     ld-2.3.2.so              do_lookup
0807a1d0 412       0.0988     cc1                      inline_forbidden_p
080f32b0 412       0.0988     cc1                      fold_convert
08262920 409       0.0981     cc1                      make_compound_operation
081dacd0 408       0.0978     cc1                      reg_fits_class_p
0810efc0 407       0.0976     cc1                      find_used_regs
080d6d70 404       0.0969     cc1                      protect_from_queue
080ef080 403       0.0966     cc1                      insn_dead_p
080a0d30 398       0.0954     cc1                      preferrable
081af7e0 398       0.0954     cc1                      expand_binop
0825d310 394       0.0945     cc1                      combine_simplify_rtx
00079600 389       0.0933     libc.so.6                strncmp
080671b0 386       0.0926     cc1                      convert
080ac1f0 386       0.0926     cc1                      insn_live_p
082170f0 386       0.0926     cc1                      layout_decl
08200fe0 384       0.0921     cc1                      reg_mentioned_p
08223480 384       0.0921     cc1                      build
0808f590 383       0.0918     cc1                      bitmap_clear
0002b6a0 381       0.0914     libc.so.6                msort_with_tmp
080a1ac0 378       0.0907     cc1                      delete_reg_equiv
08259790 375       0.0899     cc1                      try_combine
0822efb0 371       0.0890     cc1                      strip_reg_name
08251d40 371       0.0890     cc1                      make_edges
080c1e50 370       0.0887     cc1                      mem_attrs_htab_eq
08197b00 365       0.0875     cc1                      mark_all_labels
0824da10 365       0.0875     cc1                      ix86_hard_regno_mode_ok
08080be0 362       0.0868     cc1                      replace_args
080addf0 362       0.0868     cc1                      cselib_record_sets
080a03d0 360       0.0863     cc1                      convert_to_integer
081087f0 359       0.0861     cc1                      reorder_blocks_1
08081710 355       0.0851     cc1                      alloc_expansion_token
08223df0 355       0.0851     cc1                      type_hash_eq
081047b0 352       0.0844     cc1                      purge_addressof_1
081d8a80 350       0.0839     cc1                      nonimmediate_operand
0826b0a0 348       0.0835     cc1                      check_promoted_subreg
080a20a0 347       0.0832     cc1                      insert_regs
08202c40 346       0.0830     cc1                      find_reg_equal_equiv_note
081d86b0 345       0.0827     cc1                      register_operand
081e16a0 345       0.0827     cc1                      record_operand_costs
08081780 344       0.0825     cc1                      lex_expansion_token
0808f5f0 344       0.0825     cc1                      bitmap_element_allocate
0808d880 342       0.0820     cc1                      write_dependence_p
08218ae0 340       0.0815     cc1                      layout_type
081e3c00 338       0.0811     cc1                      reg_scan
080ae030 337       0.0808     cc1                      cselib_process_insn
0808e820 336       0.0806     cc1                      bitmap_clear_bit
080570a0 334       0.0801     cc1                      finish_decl
08206d40 334       0.0801     cc1                      avoid_constant_pool_reference
08250560 333       0.0799     cc1                      unchecked_make_edge
081d8db0 331       0.0794     cc1                      memory_operand
08104f50 330       0.0791     cc1                      insns_for_mem_walk
0823c140 329       0.0789     cc1                      constant_address_p
0809b7d0 328       0.0787     cc1                      find_unreachable_blocks
08236b60 328       0.0787     cc1                      alloc_page
081058e0 327       0.0784     cc1                      instantiate_virtual_regs_1
08114150 326       0.0782     cc1                      gen_rtx_fmt_ee
081d78a0 326       0.0782     cc1                      apply_change_group
08054030 324       0.0777     cc1                      poplevel
0807afb0 319       0.0765     cc1                      _cpp_handle_directive
081d8f70 319       0.0765     cc1                      asm_noperands
082addf0 319       0.0765     cc1                      xcalloc
08200670 318       0.0763     cc1                      rtx_varies_p
08068df0 316       0.0758     cc1                      verify_tree
0006e560 314       0.0753     libc.so.6                _IO_new_file_xsputn
00007330 311       0.0746     ld-2.3.2.so              _dl_elf_hash
08081810 307       0.0736     cc1                      create_iso_definition
080c7740 303       0.0727     cc1                      init_emit
081e1d50 303       0.0727     cc1                      regclass
081d75e0 300       0.0719     cc1                      validate_change
08097a10 299       0.0717     cc1                      expand_call
00079710 295       0.0707     libc.so.6                strncpy
080c41d0 295       0.0707     cc1                      change_address_1
081f1480 294       0.0705     cc1                      compute_use_by_pseudos
08209ff0 292       0.0700     cc1                      simplify_relational_operation
080acad0 291       0.0698     cc1                      rtx_equal_for_cselib_p
0808ce80 290       0.0695     cc1                      nonoverlapping_memrefs_p
08198aa0 290       0.0695     cc1                      pc_set
0810d150 288       0.0691     cc1                      compute_hash_table_work
0808c540 287       0.0688     cc1                      addr_side_effect_eval
080c6ce0 287       0.0688     cc1                      emit_insn
080c8e10 287       0.0688     cc1                      convert_from_eh_region_ranges_1
0821acf0 287       0.0688     cc1                      check_global_declarations
080ad2e0 286       0.0686     cc1                      cselib_subst_to_values
0808f760 285       0.0683     cc1                      bitmap_element_link
0819a590 285       0.0683     cc1                      lhd_tree_inlining_auto_var_in_fn_p
0821ab80 283       0.0679     cc1                      wrapup_global_declarations
08059e80 282       0.0676     cc1                      finish_struct
080c55d0 282       0.0676     cc1                      next_real_insn
081d8c80 282       0.0676     cc1                      push_operand
082065d0 281       0.0674     cc1                      uses_addressof
0829b290 279       0.0669     cc1                      find_matches
08109ea0 277       0.0664     cc1                      contains
08052530 276       0.0662     cc1                      split_specs_attrs
00078c30 275       0.0659     libc.so.6                strcpy
081e3910 273       0.0655     cc1                      allocate_reg_info
0807d650 270       0.0648     cc1                      get_effective_char
0807deb0 269       0.0645     cc1                      parse_string
0007aed0 266       0.0638     libc.so.6                __GI___mempcpy
082366f0 264       0.0633     cc1                      ggc_collect
0809b160 263       0.0631     cc1                      forwarder_block_p
08223ab0 261       0.0626     cc1                      lookup_attribute
081e1900 260       0.0624     cc1                      scan_one_insn
081f5580 260       0.0624     cc1                      eliminate_regs_in_insn
0826b190 260       0.0624     cc1                      get_last_value_validate
080aa910 259       0.0621     cc1                      invalidate_memory
0805e120 258       0.0619     cc1                      default_conversion
080da8f0 257       0.0616     cc1                      emit_move_insn
082a0220 257       0.0616     cc1                      add_dependence
080a0db0 256       0.0614     cc1                      notreg_cost
080c6040 256       0.0614     cc1                      remove_insn
082215f0 256       0.0614     cc1                      integer_onep
08089bb0 255       0.0612     cc1                      ht_expand
080c1e00 254       0.0609     cc1                      mem_attrs_htab_hash
0808d520 252       0.0604     cc1                      true_dependence
0809c8a0 251       0.0602     cc1                      delete_insn
0815f870 251       0.0602     cc1                      recog_2
08203eb0 251       0.0602     cc1                      swap_commutative_operands_p
080c2950 249       0.0597     cc1                      gen_lowpart_common
08250290 248       0.0595     cc1                      free_edge
0808e730 247       0.0592     cc1                      bitmap_copy
08079ef0 246       0.0590     cc1                      prep_stmt
0807dd60 246       0.0590     cc1                      parse_number
080eb980 244       0.0585     cc1                      output_asm_insn
081f6630 243       0.0583     cc1                      finish_spills
081f50b0 242       0.0580     cc1                      elimination_effects
0808c480 241       0.0578     cc1                      get_addr
081e5c50 238       0.0571     cc1                      push_reload
082acae0 238       0.0571     cc1                      higher_prime_number
08059860 237       0.0568     cc1                      get_parm_info
080a5030 236       0.0566     cc1                      find_comparison_args
080c5600 235       0.0564     cc1                      prev_real_insn
080dc5d0 235       0.0564     cc1                      store_expr
08217d80 234       0.0561     cc1                      place_field
0812aa90 233       0.0559     cc1                      get_attr_memory
0007ad40 232       0.0556     libc.so.6                memmove
0821b4c0 232       0.0556     cc1                      rest_of_compilation
000243f0 231       0.0554     libc.so.6                __dcigettext
00060d50 230       0.0552     libc.so.6                __find_specmb
082221f0 228       0.0547     cc1                      build_tree_list
08082200 227       0.0544     cc1                      cpp_classify_number
080a3490 226       0.0542     cc1                      rehash_using_reg
080a1720 225       0.0540     cc1                      new_basic_block
080a0cf0 222       0.0532     cc1                      approx_reg_cost
00000000 217       0.0520     ld                       (no symbols)
0808b860 215       0.0516     cc1                      find_base_value
082254f0 215       0.0516     cc1                      int_fits_type_p
0824d700 215       0.0516     cc1                      ix86_register_move_cost
0806fdd0 214       0.0513     cc1                      c_promoting_integer_type_p
080819f0 212       0.0508     cc1                      _cpp_create_definition
08224550 212       0.0508     cc1                      tree_int_cst_sgn
082797d0 212       0.0508     cc1                      calc_idoms
0823bea0 211       0.0506     cc1                      ix86_address_cost
081f1820 207       0.0496     cc1                      reload
082addc0 206       0.0494     cc1                      xmalloc
080e9be0 205       0.0492     cc1                      shorten_branches
08222120 205       0.0492     cc1                      chainon
0809cb20 203       0.0487     cc1                      create_basic_block_structure
080c1f90 203       0.0487     cc1                      gen_rtx_CONST_INT
0808c2d0 202       0.0484     cc1                      base_alias_check
080c1e90 202       0.0484     cc1                      get_mem_attrs
080dedf0 202       0.0484     cc1                      get_inner_reference
080825f0 201       0.0482     cc1                      cpp_interpret_integer
080ef610 201       0.0482     cc1                      invalidate_mems_from_autoinc
081019e0 201       0.0482     cc1                      combine_temp_slots
080ef650 200       0.0480     cc1                      invalidate_mems_from_set
0819c320 200       0.0480     cc1                      alloc_INSN_LIST
080aaa30 199       0.0477     cc1                      invalidate_from_clobbers
0829f600 198       0.0475     cc1                      copyprop_hardreg_forward_1
0002d4e0 197       0.0472     libc.so.6                __GI___strtol_internal
080ed870 197       0.0472     cc1                      calculate_global_regs_live
08188040 197       0.0472     cc1                      split_1
082adcd0 197       0.0472     cc1                      splay_tree_compare_pointers
08258390 196       0.0470     cc1                      do_SUBST
080a24f0 195       0.0468     cc1                      lookup_as_function
080ac180 195       0.0468     cc1                      set_live_p
0826ba70 195       0.0468     cc1                      mark_used_regs_combine
080806e0 194       0.0465     cc1                      collect_args
081d9ae0 193       0.0463     cc1                      extract_insn_cached
08056690 191       0.0458     cc1                      lookup_name
0805c3c0 191       0.0458     cc1                      current_stmt_tree
08224860 191       0.0458     cc1                      compare_tree_int
0829a580 191       0.0458     cc1                      regmove_optimize
082ab380 191       0.0458     cc1                      et_forest_common_ancestor
0826a980 190       0.0456     cc1                      record_value_for_reg
08200340 188       0.0451     cc1                      shallow_copy_rtx
082658c0 187       0.0448     cc1                      cached_nonzero_bits
0819a4f0 185       0.0444     cc1                      lhd_tree_inlining_walk_subtrees
08202620 185       0.0444     cc1                      note_uses
082188e0 185       0.0444     cc1                      finalize_type_size
0828b570 184       0.0441     cc1                      build_insn_chain
080c5590 181       0.0434     cc1                      next_nonnote_insn
080c8b00 181       0.0434     cc1                      remove_fixup_regions
08114e90 180       0.0432     cc1                      ggc_alloc_cleared
0809ce70 178       0.0427     cc1                      free_bb_for_insn
0823fe90 177       0.0424     cc1                      ix86_expand_move
08052ee0 175       0.0420     cc1                      interpret_integer
0810cee0 175       0.0420     cc1                      record_last_reg_set_info
082aaf70 174       0.0417     cc1                      remove_all_occurrences
080c8c60 173       0.0415     cc1                      remove_unreachable_regions
080f0b50 171       0.0410     cc1                      count_or_remove_death_notes
082663e0 171       0.0410     cc1                      num_sign_bit_copies1
0826ae20 171       0.0410     cc1                      record_dead_and_set_regs
08080ab0 169       0.0405     cc1                      enter_macro_context
080a3350 169       0.0405     cc1                      remove_invalid_refs
08108b90 169       0.0405     cc1                      prepare_function_start
080adc30 167       0.0400     cc1                      cselib_record_set
080dbf00 166       0.0398     cc1                      get_subtarget
0819cf20 166       0.0398     cc1                      update_equiv_regs
081f5490 165       0.0396     cc1                      check_eliminable_occurrences
0823aec0 164       0.0393     cc1                      ix86_save_reg
0809cea0 163       0.0391     cc1                      update_bb_for_insn
08228950 163       0.0391     cc1                      inlinable_function_p
08258ce0 163       0.0391     cc1                      can_combine_p
081d8d70 160       0.0384     cc1                      memory_address_p
00080720 159       0.0381     libc.so.6                __GI___mbrtowc
0000aed0 159       0.0381     libpthread.so.0          __pthread_alt_unlock
080f0e50 159       0.0381     cc1                      encode
08198bd0 158       0.0379     cc1                      returnjump_p_1
082197f0 158       0.0379     cc1                      ggc_alloc_string
08187c80 157       0.0377     cc1                      recog
0819daa0 157       0.0377     cc1                      block_alloc
082179c0 157       0.0377     cc1                      update_alignment_for_field
0805f480 156       0.0374     cc1                      parser_build_binary_op
080adb90 156       0.0374     cc1                      cselib_invalidate_rtx
08232da0 155       0.0372     cc1                      mark_constants
080a7000 154       0.0369     cc1                      equiv_constant
0819fbd0 154       0.0369     cc1                      requires_inout
081062e0 152       0.0365     cc1                      aggregate_value_p
08240240 152       0.0365     cc1                      ix86_expand_binary_operator
0812e6a0 151       0.0362     cc1                      get_attr_type
082037d0 151       0.0362     cc1                      replace_regs
0821a640 151       0.0362     cc1                      floor_log2_wide
081938c0 149       0.0357     cc1                      save_for_inline
081f8f40 149       0.0357     cc1                      choose_reload_regs
08210ef0 149       0.0357     cc1                      expand_expr_stmt_value
08212990 148       0.0355     cc1                      expand_start_bindings_and_block
0828d140 148       0.0355     cc1                      schedule_insn
0828e970 148       0.0355     cc1                      schedule_block
080c7210 147       0.0353     cc1                      start_sequence
08053250 146       0.0350     cc1                      lex_string
081ef8d0 146       0.0350     cc1                      find_equiv_reg
00000000 146       0.0350     ISO8859-1.so             (no symbols)
0824d510 145       0.0348     cc1                      ix86_secondary_memory_needed
0808ae30 144       0.0345     cc1                      mems_in_disjoint_alias_sets_p
080a2450 144       0.0345     cc1                      lookup_for_remove
080cd070 144       0.0345     cc1                      memory_address
081d9b20 144       0.0345     cc1                      extract_constrain_insn_cached
08225750 144       0.0345     cc1                      decl_function_context
080793f0 143       0.0343     cc1                      build_stmt
080a17f0 143       0.0343     cc1                      make_new_qty
08198b10 142       0.0341     cc1                      any_condjump_p
08223750 142       0.0341     cc1                      build_decl
082244a0 142       0.0341     cc1                      tree_low_cst
08212f60 141       0.0338     cc1                      expand_end_bindings
082a0e70 141       0.0338     cc1                      sched_analyze_2
08062730 140       0.0336     cc1                      convert_for_assignment
082132a0 140       0.0336     cc1                      expand_decl
08227e20 140       0.0336     cc1                      remap_decl
080dab40 139       0.0333     cc1                      emit_move_insn_1
081e35c0 139       0.0333     cc1                      record_address_regs
080a22f0 137       0.0329     cc1                      remove_from_table
080f0e80 137       0.0329     cc1                      decode
0819a1b0 137       0.0329     cc1                      true_regnum
08279390 137       0.0329     cc1                      calc_dfs_tree_nonrec
0001ee30 137       0.0329     libbfd-2.14.90.0.5.so    bfd_hash_lookup
080a2ea0 136       0.0326     cc1                      check_dependence
080ac630 136       0.0326     cc1                      new_elt_loc_list
080c73c0 136       0.0326     cc1                      end_sequence
080cb0b0 136       0.0326     cc1                      can_throw_internal
08202b70 136       0.0326     cc1                      find_regno_note
0826a810 136       0.0326     cc1                      update_table_tick
080ab8c0 135       0.0324     cc1                      cse_main
0828ce90 135       0.0324     cc1                      priority
0809ca60 134       0.0321     cc1                      delete_insn_chain
080c25d0 134       0.0321     cc1                      gen_reg_rtx
080ea960 133       0.0319     cc1                      final_scan_insn
08279690 133       0.0319     cc1                      link_roots
08052a70 132       0.0317     cc1                      cb_line_change
0809fc80 132       0.0317     cc1                      purge_dead_edges
08112ba0 132       0.0317     cc1                      invalidate_any_buried_refs
08114940 132       0.0317     cc1                      gen_rtx_fmt_i0
081d88a0 132       0.0317     cc1                      immediate_operand
082adb40 132       0.0317     cc1                      splay_tree_lookup
0809d120 131       0.0314     cc1                      merge_blocks_nomove
080aab20 131       0.0314     cc1                      cse_process_notes
0822f0f0 131       0.0314     cc1                      make_decl_rtl
080c5300 130       0.0312     cc1                      get_insns
08217030 130       0.0312     cc1                      round_up
080ac710 129       0.0309     cc1                      clear_table
080cced0 129       0.0309     cc1                      break_out_memory_refs
080ee4a0 129       0.0309     cc1                      allocate_reg_life_data
080eed20 129       0.0309     cc1                      init_propagate_block_info
0810ec60 129       0.0309     cc1                      compute_transp
0810fd80 129       0.0309     cc1                      local_cprop_pass
081f3cb0 129       0.0309     cc1                      find_reload_regs
08117080 128       0.0307     cc1                      hook_bool_tree_false
0805ae00 127       0.0305     cc1                      start_function
0809df30 127       0.0305     cc1                      tidy_fallthru_edge
080c5630 127       0.0305     cc1                      active_insn_p
081f2e70 127       0.0305     cc1                      calculate_needs_all_insns
081f3400 126       0.0302     cc1                      order_regs_for_reload
08205130 126       0.0302     cc1                      sbitmap_vector_alloc
08266fc0 126       0.0302     cc1                      simplify_shift_const
080df590 126       0.0302     XFree86                  WaitForSomething
08198c40 125       0.0300     cc1                      onlyjump_p
08289230 125       0.0300     cc1                      allocno_compare
08053e20 124       0.0297     cc1                      pop_binding_level
081f6c10 124       0.0297     cc1                      scan_paradoxical_subregs
082530a0 124       0.0297     cc1                      thread_jump
0805c3b0 123       0.0295     cc1                      stmts_are_full_exprs_p
081e8470 122       0.0293     cc1                      operands_match_p
082584e0 122       0.0293     cc1                      combine_instructions
08250660 121       0.0290     cc1                      cached_make_edge
082a2760 121       0.0290     cc1                      free_deps
081ab960 120       0.0288     cc1                      canonicalize_condition
08210a00 120       0.0288     cc1                      check_operand_nalternatives
080cc990 119       0.0285     cc1                      plus_constant_wide
08198ae0 119       0.0285     cc1                      any_uncondjump_p
080ad990 118       0.0283     cc1                      cselib_mem_conflict_p
080d6f90 118       0.0283     cc1                      emit_queue
080dbf40 118       0.0283     cc1                      expand_assignment
081149c0 118       0.0283     cc1                      gen_rtx_fmt_e0
082641b0 118       0.0283     cc1                      if_then_else_cond
08056d90 117       0.0281     cc1                      start_decl
0805bd00 117       0.0281     cc1                      c_expand_body
0805eaa0 117       0.0281     cc1                      build_external_ref
08203a10 117       0.0281     cc1                      computed_jump_p_1
0823c070 117       0.0281     cc1                      legitimate_constant_p
00015f40 116       0.0278     libc.so.6                __GI___errno_location
080ad1c0 116       0.0278     cc1                      cselib_lookup_mem
0828cd20 116       0.0278     cc1                      insn_cost
0809dfe0 115       0.0276     cc1                      tidy_fallthru_edges
08201c60 115       0.0276     cc1                      noop_move_p
08289320 115       0.0276     cc1                      global_conflicts
080a7390 114       0.0273     cc1                      record_jump_cond
080ad0b0 114       0.0273     cc1                      new_cselib_val
080c2220 113       0.0271     cc1                      gen_rtx_REG
08101dc0 112       0.0269     cc1                      preserve_temp_slots
0810f9e0 112       0.0269     cc1                      do_local_cprop
081dadc0 112       0.0269     cc1                      split_insn
080cc910 111       0.0266     cc1                      trunc_int_for_mode
00026670 110       0.0264     libc.so.6                read_alias_file
080512f0 110       0.0264     gcc                      handle_braces
0000b990 109       0.0261     ld-2.3.2.so              fixup
08079b90 109       0.0261     cc1                      genrtl_scope_stmt
080c5c20 109       0.0261     cc1                      make_insn_raw
081d7ae0 109       0.0261     cc1                      validate_replace_rtx_1
08053f00 108       0.0259     cc1                      pushlevel
080f39e0 108       0.0259     cc1                      operand_equal_p
081f47c0 108       0.0259     cc1                      eliminate_regs
082a09e0 108       0.0259     cc1                      sched_analyze_1
0805e350 107       0.0257     cc1                      lookup_field
080a3e10 107       0.0257     cc1                      safe_hash
080e68c0 107       0.0257     cc1                      do_jump
08222170 107       0.0257     cc1                      nreverse
08212ef0 106       0.0254     cc1                      warn_about_unused_variables
0805ee80 105       0.0252     cc1                      convert_arguments
080c6e80 105       0.0252     cc1                      emit_line_note
080f2f50 105       0.0252     cc1                      size_int_wide
0810c960 105       0.0252     cc1                      hash_scan_set
081fbc60 105       0.0252     cc1                      emit_reload_insns
08246580 105       0.0252     cc1                      ix86_adjust_cost
082a0650 105       0.0252     cc1                      add_dependence_list_and_free
08289c10 104       0.0249     cc1                      find_reg
080c1d50 103       0.0247     cc1                      const_int_htab_eq
082ad9c0 103       0.0247     cc1                      splay_tree_insert
00006d00 102       0.0245     libpthread.so.0          __GI___pthread_mutex_trylock
08111a90 102       0.0245     cc1                      delete_null_pointer_checks_1
08268950 102       0.0245     cc1                      simplify_comparison
0807a2d0 101       0.0242     cc1                      c_cannot_inline_tree_fn
081a4320 101       0.0242     cc1                      find_single_use_in_loop
081d71f0 101       0.0242     cc1                      get_zero
0820f740 101       0.0242     cc1                      parse_input_constraint
08227fb0 101       0.0242     cc1                      remap_block
082632c0 101       0.0242     cc1                      force_to_mode
08060c10 100       0.0240     cc1                      build_unary_op
0807ad90 100       0.0240     cc1                      end_directive
08101fd0 100       0.0240     cc1                      free_temp_slots
081ef230 100       0.0240     cc1                      refers_to_regno_for_reload_p
080c1f60 98        0.0235     cc1                      gen_raw_REG
08216e40 98        0.0235     cc1                      mode_for_size
082ad860 98        0.0235     cc1                      splay_tree_splay
0810c2b0 97        0.0233     cc1                      expr_equiv_p
000db6e0 96        0.0230     libc.so.6                __mmap
08193380 96        0.0230     cc1                      function_attribute_inlinable_p
08199810 96        0.0230     cc1                      redirect_exp_1
081fdb50 96        0.0230     cc1                      reload_cse_simplify
0002b880 95        0.0228     libc.so.6                __GI_qsort
08068bb0 95        0.0228     cc1                      add_tlist
08068c20 95        0.0228     cc1                      merge_tlist
08109f20 95        0.0228     cc1                      prologue_epilogue_contains
0819b9f0 95        0.0228     cc1                      optimize_mode_switching
081d93d0 95        0.0228     cc1                      asm_operand_ok
082a21c0 95        0.0228     cc1                      sched_analyze
0007ab80 94        0.0225     libc.so.6                __memchr
080c20c0 94        0.0225     cc1                      immed_double_const
08095c10 93        0.0223     cc1                      special_function_p
080c57b0 93        0.0223     cc1                      try_split
0819c2e0 93        0.0223     cc1                      free_list
0809d2e0 92        0.0221     cc1                      try_redirect_by_replacing_jump
080c4c80 92        0.0221     cc1                      unshare_all_rtl_1
082211c0 92        0.0221     cc1                      build_int_2_wide
082ad650 92        0.0221     cc1                      splay_tree_delete_helper
00000000 92        0.0221     nm                       (no symbols)
00023b50 91        0.0218     libc.so.6                __ctype_b_loc
0807a180 91        0.0218     cc1                      c_disregard_inline_limits
0808b220 91        0.0218     cc1                      get_alias_set
080df6f0 91        0.0218     cc1                      safe_from_p
08217750 91        0.0218     cc1                      normalize_offset
0006f470 90        0.0216     libc.so.6                _IO_default_xsputn_internal
080575a0 90        0.0216     cc1                      push_parm_decl
0805b3a0 90        0.0216     cc1                      store_parm_decls
08128f70 90        0.0216     cc1                      function_units_used
081f1380 90        0.0216     cc1                      new_insn_chain
08235a80 90        0.0216     cc1                      varray_init
082365a0 90        0.0216     cc1                      ggc_pop_context
0806b0a0 89        0.0213     cc1                      c_apply_type_quals_to_decl
080810a0 89        0.0213     cc1                      expand_arg
0818ff10 89        0.0213     cc1                      peephole2_1
0820ef20 89        0.0213     cc1                      expand_fixup
0807a510 88        0.0211     cc1                      expand_deferred_fns
080c2310 88        0.0211     cc1                      gen_rtx_MEM
0829eb30 88        0.0211     cc1                      kill_autoinc_value
001132fe 87        0.0209     libc.so.6                __i686.get_pc_thunk.cx
08108e60 87        0.0209     cc1                      init_function_start
08109840 87        0.0209     cc1                      expand_function_end
0820e8c0 87        0.0209     cc1                      set_file_and_line_for_stmt
08216c20 87        0.0209     cc1                      get_pending_sizes
08216fe0 87        0.0209     cc1                      get_mode_alignment
08224320 87        0.0209     cc1                      tree_int_cst_lt
08279a30 87        0.0209     cc1                      calculate_dominance_info
08079230 86        0.0206     cc1                      add_stmt
080c47d0 86        0.0206     cc1                      replace_equiv_address_nv
0819af30 86        0.0206     cc1                      compute_available
0820adc0 86        0.0206     cc1                      simplify_subreg
0807e170 85        0.0204     cc1                      _cpp_temp_token
08109170 84        0.0201     cc1                      expand_function_start
081782f0 84        0.0201     cc1                      recog_19
0820f520 84        0.0201     cc1                      parse_output_constraint
082662b0 84        0.0201     cc1                      cached_num_sign_bit_copies
082a0600 84        0.0201     cc1                      add_dependence_list
081143f0 83        0.0199     cc1                      gen_rtx_fmt_e
0819c410 83        0.0199     cc1                      free_INSN_LIST_list
0828de00 83        0.0199     cc1                      find_insn_reg_weight
0804c1e0 82        0.0197     gcc                      process_command

Re: gcc 3.5 integration branch proposal

[Jan Hubicka]

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

> In fact, I finally got around to building gcc-head, and comparing it
> to gcc 3.3.2.
> 
> To say that the results are disappointing would be an understatement:
> 
> Time for a kernel compile, gcc 3.3.2:
>   276.63s real   193.01s user    26.86s system
> with gcc-head:
>   341.31s real   213.25s user    27.87s system
> 
> Exact same options, basically -O2.
> 
> Now, tell me again that GCC is getting faster...

This is precisely what I intend to do now, yes.
I re-did your experiment on my notebook (Centrino, 256MB ram) with Linux
kernel 2.6.1.  I disabled checking and profiledbootstrapped mainline, 
and compared it to current disabled checking bootstrapped 3.2 branch.

For 3.4 I get:
real    6m44.513s
user    6m13.057s
sys     0m23.915s

For 3.2 I get:
real    7m53.661s
user    7m19.730s
sys     0m24.206s

A 17% speedup (I re-did the 3.2 test 3 times with ~10 second
fluctulation).  Compare it to difference in between 2.95 and 3.2 and I
think you can clearly notice that speed issues are improving, tought the
progress is not as fast as we all would wish.  Additionally I get 250Kb
savings on 5MB vmlinux binary.

I just noticed that you did used 3.3 instead of 3.2.  I will re-do with
3.3 tree, but it is unlikely I will find it another 23% faster, but I
will give it a try.

Of course this is not claiming that it is impossible to find situation
where GCC performs like you reported.  So in order to solve your
problem, you need to be more specific about your environment and provide
either a profiles or a way to reproduce it for us.
In the case you do worry about performance of GCC, you can do a lot even
without active development of GCC.  The existence of CSiBE benchmark and
Gerald's testcase itself made the situation a lot better compilation
time wise, similarly as existence of SPEC testing machines did to the
performance

I am attaching oprofiles in the case someone will find them interesting.

Honza

[-- Attachment #2: 3.2 --]
[-- Type: text/plain, Size: 38492 bytes --]

CPU: CPU with timer interrupt, speed 1299.43 MHz (estimated)
Profiling through timer interrupt
vma      samples  %           app name                 symbol name
0007ae60 23852     5.5482     libc.so.6                memset
081eef50 14497     3.3721     cc1                      ggc_set_mark
08049640 14352     3.3384     cc1                      yyparse_1
080579a0 11083     2.5780     cc1                      finish_struct
081eed80 10339     2.4049     cc1                      ggc_alloc
080fb250 8728      2.0302     cc1                      ggc_mark_trees
0827efd0 7046      1.6390     cc1                      htab_find_slot_with_hash
081c31c0 6672      1.5520     cc1                      for_each_rtx
0807f930 6168      1.4347     cc1                      ht_lookup
0809bad0 5667      1.3182     cc1                      cse_insn
00074fd0 5488      1.2766     libc.so.6                _int_malloc
081e6a20 5121      1.1912     cc1                      walk_tree
08076110 4026      0.9365     cc1                      _cpp_lex_direct
00000000 3434      0.7988     as                       (no symbols)
0827eee0 3249      0.7557     cc1                      htab_find_with_hash
00077f20 3201      0.7446     libc.so.6                strcmp
080df850 3062      0.7122     cc1                      mark_set_1
08094d60 2963      0.6892     cc1                      approx_reg_cost
081a3ba0 2837      0.6599     cc1                      reg_scan_mark_refs
080fb000 2803      0.6520     cc1                      ggc_mark_rtx_children_1
08054050 2768      0.6439     cc1                      lookup_tag
08083af0 2764      0.6429     cc1                      init_alias_analysis
081a2020 2708      0.6299     cc1                      record_reg_classes
0819e690 2654      0.6173     cc1                      constrain_operands
08055640 2650      0.6164     cc1                      grokdeclarator
08075710 2505      0.5827     cc1                      parse_identifier
081c1bc0 2459      0.5720     cc1                      note_stores
080de6f0 2389      0.5557     cc1                      propagate_one_insn
08081a90 2351      0.5469     cc1                      canon_rtx
000793f0 2336      0.5434     libc.so.6                strlen
080986d0 2278      0.5299     cc1                      canon_reg
081c2840 2241      0.5213     cc1                      side_effects_p
0807f840 2238      0.5206     cc1                      calc_hash
08099300 2221      0.5166     cc1                      fold_rtx
08180bd0 2205      0.5129     cc1                      mark_jump_label
081de590 2156      0.5015     cc1                      make_node
08094fb0 2127      0.4948     cc1                      rtx_cost
08075400 2126      0.4945     cc1                      skip_block_comment
00000000 2122      0.4936     gzip                     (no symbols)
080e8cd0 2098      0.4880     cc1                      fold
081ef380 2014      0.4685     cc1                      ggc_pop_context
081a8750 1992      0.4634     cc1                      find_reloads
08078c40 1831      0.4259     cc1                      cpp_get_token
08096df0 1791      0.4166     cc1                      invalidate
081c21c0 1739      0.4045     cc1                      find_reg_note
080e0df0 1686      0.3922     cc1                      force_fit_type
080d0a60 1678      0.3903     cc1                      expand_expr
0804ec00 1673      0.3892     cc1                      c_lex
080964e0 1647      0.3831     cc1                      insert
080e21c0 1602      0.3726     cc1                      int_const_binop
080e0380 1563      0.3636     cc1                      mark_used_regs
081a01e0 1522      0.3540     cc1                      init_reg_sets_1
080977b0 1515      0.3524     cc1                      canon_hash
08203600 1451      0.3375     cc1                      bitmap_set_bit
00000000 1407      0.3273     make                     (no symbols)
08076030 1395      0.3245     cc1                      _cpp_lex_token
080955f0 1386      0.3224     cc1                      get_cse_reg_info
080489a0 1385      0.3222     fixdep                   parse_config_file
08203700 1306      0.3038     cc1                      bitmap_bit_p
0007b5e0 1281      0.2980     libc.so.6                memcpy
000755e0 1260      0.2931     libc.so.6                _int_free
081bfb30 1250      0.2908     cc1                      rtx_equal_p
0819c9a0 1218      0.2833     cc1                      general_operand
081c6540 1218      0.2833     cc1                      simplify_binary_operation
080e2f00 1215      0.2826     cc1                      size_htab_eq
081f3ce0 1199      0.2789     cc1                      ix86_decompose_address
081de4c0 1183      0.2752     cc1                      tree_size
0827f780 1162      0.2703     cc1                      splay_tree_splay_helper
08097d50 1147      0.2668     cc1                      exp_equiv_p
081de730 1146      0.2666     cc1                      copy_node
081bd6b0 1139      0.2649     cc1                      reload_cse_simplify_operands
081f4190 1139      0.2649     cc1                      legitimate_address_p
081c1510 1128      0.2624     cc1                      refers_to_regno_p
081d8370 1122      0.2610     cc1                      timevar_pop
080b6350 1117      0.2598     cc1                      copy_rtx_if_shared
0819dfd0 1100      0.2559     cc1                      extract_insn
081a3f70 1098      0.2554     cc1                      reg_class_subset_p
08207a30 1079      0.2510     cc1                      find_basic_blocks_1
081e61d0 1061      0.2468     cc1                      expand_call_inline
080755d0 995       0.2314     cc1                      skip_whitespace
0827f250 979       0.2277     cc1                      htab_find_slot
08095af0 970       0.2256     cc1                      mention_regs
08081860 969       0.2254     cc1                      record_set
00074100 951       0.2212     libc.so.6                __malloc
000742d0 949       0.2207     libc.so.6                __cfree
00074980 925       0.2152     libc.so.6                __calloc
08207170 921       0.2142     cc1                      control_flow_insn_p
080e30a0 907       0.2110     cc1                      size_binop
080e1000 899       0.2091     cc1                      mul_double
081e59b0 898       0.2089     cc1                      copy_body_r
00000000 892       0.2075     bash                     (no symbols)
080e2f80 892       0.2075     cc1                      size_int_type_wide
080fafa0 878       0.2042     cc1                      ggc_mark_rtx_children
080dfff0 856       0.1991     cc1                      mark_used_reg
081c3350 853       0.1984     cc1                      commutative_operand_precedence
00007600 840       0.1954     ld-2.3.2.so              do_lookup_versioned
08075580 834       0.1940     cc1                      adjust_column
0804c9d0 820       0.1907     cc1                      yylex
081d8290 815       0.1896     cc1                      timevar_push
00075800 807       0.1877     libc.so.6                malloc_consolidate
0804cb70 775       0.1803     cc1                      _yylex
081e7d70 775       0.1803     cc1                      decode_reg_name
0804ed20 773       0.1798     cc1                      lex_number
081e2c40 768       0.1786     cc1                      variably_modified_type_p
08094d20 762       0.1772     cc1                      approx_reg_cost_1
0809fe00 751       0.1747     cc1                      count_reg_usage
0809f320 717       0.1668     cc1                      cse_end_of_basic_block
080b4b20 710       0.1652     cc1                      set_mem_attributes_minus_bitpos
081dfda0 696       0.1619     cc1                      first_rtl_op
0806c3f0 689       0.1603     cc1                      statement_code_p
08248c60 686       0.1596     cc1                      insn_extract
082038d0 684       0.1591     cc1                      bitmap_operation
080b7060 680       0.1582     cc1                      add_insn
08048ff8 671       0.1561     cc1                      anonymous symbol from section .plt
082070e0 662       0.1540     cc1                      inside_basic_block_p
00047c40 637       0.1482     libc.so.6                _IO_vfprintf_internal
08072710 636       0.1479     cc1                      inline_forbidden_p
0804cf60 634       0.1475     cc1                      decl_attributes
08222190 634       0.1475     cc1                      cselib_lookup
00011410 629       0.1463     ld-2.3.2.so              strcmp
081e6f70 624       0.1451     cc1                      copy_tree_r
00077d50 622       0.1447     libc.so.6                index
00015b8f 618       0.1438     libc.so.6                __i686.get_pc_thunk.bx
0820a530 616       0.1433     cc1                      try_optimize_cfg
08204050 597       0.1389     cc1                      bitmap_clear
08097500 595       0.1384     cc1                      invalidate_for_call
080b6520 595       0.1384     cc1                      reset_used_flags
0827f350 588       0.1368     cc1                      htab_traverse
0809f990 587       0.1365     cc1                      cse_basic_block
00079600 577       0.1342     libc.so.6                strncmp
081e0bd0 575       0.1337     cc1                      build1
08075150 571       0.1328     cc1                      handle_newline
080fa8d0 568       0.1321     cc1                      gen_rtx_fmt_i0
08059fa0 564       0.1312     cc1                      lang_mark_tree
080962c0 562       0.1307     cc1                      lookup
080e2ed0 561       0.1305     cc1                      size_htab_hash
081dec30 558       0.1298     cc1                      integer_zerop
08219640 555       0.1291     cc1                      nonzero_bits
08081e80 554       0.1289     cc1                      find_base_term
080e0cf0 552       0.1284     cc1                      reg_set_to_hard_reg_set
082040a0 550       0.1279     cc1                      bitmap_element_allocate
08081b80 544       0.1265     cc1                      rtx_equal_for_memref_p
080487e0 540       0.1256     fixdep                   is_defined_config
0002ba00 539       0.1254     libc.so.6                __GI_getenv
0809fda0 528       0.1228     cc1                      check_for_label_ref
08210f20 521       0.1212     cc1                      subst
081bf850 513       0.1193     cc1                      rtx_alloc
082041c0 513       0.1193     cc1                      bitmap_element_link
081c2790 508       0.1182     cc1                      volatile_refs_p
081c1080 507       0.1179     cc1                      single_set_2
000095d0 505       0.1175     ld-2.3.2.so              _dl_relocate_object_internal
081df8f0 504       0.1172     cc1                      tree_cons
0817f890 493       0.1147     cc1                      init_label_info
08202ab0 493       0.1147     cc1                      ix86_memory_move_cost
081c0690 492       0.1144     cc1                      reg_mentioned_p
081e1b20 492       0.1144     cc1                      host_integerp
0819e230 482       0.1121     cc1                      preprocess_constraints
080b8c10 481       0.1119     cc1                      mark_emit_status
080b8090 479       0.1114     cc1                      emit_note
08268060 478       0.1112     cc1                      sched_analyze_insn
080791e0 477       0.1110     cc1                      _cpp_create_definition
08082340 477       0.1110     cc1                      memrefs_conflict_p
080f4f80 472       0.1098     cc1                      assign_parms
081e0a40 470       0.1093     cc1                      build
08207250 466       0.1084     cc1                      count_basic_blocks
081c7f10 461       0.1072     cc1                      simplify_plus_minus
0827ef90 458       0.1065     cc1                      htab_find
081bfdf0 457       0.1063     cc1                      rtx_varies_p
080c28f0 455       0.1058     cc1                      synth_mult
0804c930 447       0.1040     cc1                      yylexname
080533a0 443       0.1030     cc1                      pushdecl
081c1850 442       0.1028     cc1                      reg_overlap_mentioned_p
080def60 441       0.1026     cc1                      propagate_block
08221a40 432       0.1005     cc1                      hash_rtx
0002dc10 430       0.1000     libc.so.6                __GI___strtoul_internal
081bf890 429       0.0998     cc1                      copy_rtx
08208b40 429       0.0998     cc1                      try_forward_edges
0805cd70 426       0.0991     cc1                      build_binary_op
081a3fd0 426       0.0991     cc1                      reg_classes_intersect_p
000073c0 425       0.0989     ld-2.3.2.so              do_lookup
08216690 424       0.0986     cc1                      make_compound_operation
081ce1a0 422       0.0982     cc1                      expand_asm_operands
0827ece0 421       0.0979     cc1                      hash_pointer
081df790 413       0.0961     cc1                      list_length
080988e0 409       0.0951     cc1                      find_best_addr
080f7420 400       0.0930     cc1                      reorder_blocks_1
0820dac0 397       0.0923     cc1                      try_combine
0827feb0 397       0.0923     cc1                      xcalloc
08072490 394       0.0916     cc1                      expand_stmt
08095a50 393       0.0914     cc1                      delete_reg_equiv
0807fbc0 392       0.0912     cc1                      ht_forall
080c80f0 391       0.0909     cc1                      protect_from_queue
0817f940 390       0.0907     cc1                      mark_all_labels
082074b0 387       0.0900     cc1                      make_edges
080b7d80 386       0.0898     cc1                      emit_insn
081a1590 386       0.0898     cc1                      record_operand_costs
080b3660 384       0.0893     cc1                      gen_rtx_REG
080916a0 380       0.0884     cc1                      compute_bb_for_insn
0819cbf0 379       0.0882     cc1                      register_operand
08095fa0 377       0.0877     cc1                      insert_regs
080b8600 375       0.0872     cc1                      gen_sequence
08078690 374       0.0870     cc1                      replace_args
080e33a0 374       0.0870     cc1                      fold_convert
080b68c0 372       0.0865     cc1                      next_real_insn
08094eb0 371       0.0863     cc1                      preferrable
081576d0 368       0.0856     cc1                      recog_16
0819cee0 368       0.0856     cc1                      nonimmediate_operand
080df6e0 367       0.0854     cc1                      mark_set_regs
08079150 362       0.0842     cc1                      lex_expansion_token
0819f080 362       0.0842     cc1                      reg_fits_class_p
08064540 361       0.0840     cc1                      convert
081e7d50 361       0.0840     cc1                      strip_reg_name
08211640 360       0.0837     cc1                      combine_simplify_rtx
080944f0 359       0.0835     cc1                      convert_to_integer
0821e2a0 359       0.0835     cc1                      check_promoted_subreg
08050710 354       0.0823     cc1                      c_decode_option
080790e0 354       0.0823     cc1                      alloc_expansion_token
08202910 354       0.0823     cc1                      ix86_hard_regno_mode_ok
08261f60 338       0.0786     cc1                      find_matches
081d5740 337       0.0784     cc1                      layout_decl
0006e560 333       0.0775     libc.so.6                _IO_new_file_xsputn
0002b6a0 332       0.0772     libc.so.6                msort_with_tmp
081a39f0 332       0.0772     cc1                      reg_scan
0827ecf0 330       0.0768     cc1                      eq_pointer
0808bfb0 329       0.0765     cc1                      expand_call
080f43e0 326       0.0758     cc1                      instantiate_virtual_regs_1
081d6ff0 326       0.0758     cc1                      layout_type
081e13e0 322       0.0749     cc1                      type_hash_eq
080df0b0 321       0.0747     cc1                      insn_dead_p
08186ed0 320       0.0744     cc1                      expand_binop
08182200 315       0.0733     cc1                      lhd_tree_inlining_auto_var_in_fn_p
080fa170 313       0.0728     cc1                      gen_rtx_fmt_ee
080f3320 312       0.0726     cc1                      purge_addressof_1
081eefd0 311       0.0723     cc1                      ggc_marked_p
082034c0 311       0.0723     cc1                      bitmap_clear_bit
081f40a0 310       0.0721     cc1                      ix86_find_base_term
08238660 309       0.0719     cc1                      compute_hash_table
081c1210 307       0.0714     cc1                      set_noop_p
08051ad0 301       0.0700     cc1                      poplevel
0819bea0 298       0.0693     cc1                      apply_change_group
080815f0 297       0.0691     cc1                      find_base_value
081e0fb0 297       0.0691     cc1                      is_attribute_p
00007330 295       0.0686     ld-2.3.2.so              _dl_elf_hash
00079710 294       0.0684     libc.so.6                strncpy
081c4da0 294       0.0684     cc1                      uses_addressof
08222710 294       0.0684     cc1                      cselib_invalidate_mem_1
081c5510 293       0.0682     cc1                      avoid_constant_pool_reference
08098f00 292       0.0679     cc1                      find_comparison_args
0804e360 290       0.0675     cc1                      split_specs_attrs
0827fe80 290       0.0675     cc1                      xmalloc
081d6170 288       0.0670     cc1                      place_field
081b0e70 287       0.0668     cc1                      compute_use_by_pseudos
080b6920 282       0.0656     cc1                      active_insn_p
081ded00 280       0.0651     cc1                      integer_onep
081a56e0 279       0.0649     cc1                      push_reload
080753b0 274       0.0637     cc1                      get_effective_char
08222430 274       0.0637     cc1                      cselib_invalidate_regno
081d7f40 273       0.0635     cc1                      mark_ident
0808fed0 272       0.0633     cc1                      find_unreachable_blocks
080f8a50 272       0.0633     cc1                      contains
08066120 271       0.0630     cc1                      verify_tree
080f3af0 270       0.0628     cc1                      insns_for_mem_walk
00078c30 268       0.0623     libc.so.6                strcpy
081df7e0 267       0.0621     cc1                      chainon
08083250 266       0.0619     cc1                      true_dependence
08221720 266       0.0619     cc1                      rtx_equal_for_cselib_p
08266380 265       0.0616     cc1                      copyprop_hardreg_forward_1
081b4ec0 264       0.0614     cc1                      eliminate_regs_in_insn
081a1c10 263       0.0612     cc1                      regclass
080b3540 260       0.0605     cc1                      gen_raw_REG
081a17e0 260       0.0605     cc1                      scan_one_insn
08072f80 259       0.0602     cc1                      _cpp_handle_directive
08097360 259       0.0602     cc1                      rehash_using_reg
08091220 256       0.0595     cc1                      delete_insn
0827fd90 255       0.0593     cc1                      splay_tree_compare_pointers
0809e820 254       0.0591     cc1                      invalidate_memory
080ba6a0 253       0.0588     cc1                      convert_from_eh_region_ranges_1
0819d0f0 252       0.0586     cc1                      push_operand
081d9120 252       0.0586     cc1                      wrapup_global_declarations
08054e50 251       0.0584     cc1                      finish_decl
081808d0 251       0.0584     cc1                      pc_set
0819d3a0 249       0.0579     cc1                      asm_noperands
08075cb0 248       0.0577     cc1                      parse_string
0007aed0 247       0.0575     libc.so.6                __GI___mempcpy
08082bc0 247       0.0575     cc1                      nonoverlapping_memrefs_p
0808f7b0 247       0.0575     cc1                      forwarder_block_p
0807fb00 246       0.0572     cc1                      ht_expand
080f1900 244       0.0568     cc1                      fixup_var_refs_1
08205f80 244       0.0568     cc1                      cached_make_edge
080b7330 243       0.0565     cc1                      remove_insn
0819d200 243       0.0565     cc1                      memory_operand
080b3380 242       0.0563     cc1                      mem_attrs_htab_eq
08221fa0 240       0.0558     cc1                      cselib_subst_to_values
0809e910 238       0.0554     cc1                      invalidate_from_clobbers
080cd210 238       0.0554     cc1                      store_expr
081b1210 238       0.0554     cc1                      reload
080d9de0 234       0.0544     cc1                      shorten_branches
081c3410 234       0.0544     cc1                      swap_commutative_operands_p
080956a0 233       0.0542     cc1                      new_basic_block
0819bc10 231       0.0537     cc1                      validate_change
08222a40 231       0.0537     cc1                      cselib_record_sets
0007ad40 229       0.0533     libc.so.6                memmove
081b49e0 229       0.0533     cc1                      elimination_effects
080b3330 228       0.0530     cc1                      mem_attrs_htab_hash
080dba00 228       0.0530     cc1                      output_asm_insn
081fd070 228       0.0530     cc1                      ix86_mark_machine_status
0821eb80 228       0.0530     cc1                      mark_used_regs_combine
081a3700 227       0.0528     cc1                      allocate_reg_info
0805b6c0 225       0.0523     cc1                      default_conversion
081ef870 223       0.0519     cc1                      alloc_page
08075a40 222       0.0516     cc1                      parse_number
08266f50 221       0.0514     cc1                      add_dependence
080573d0 220       0.0512     cc1                      get_parm_info
0814b6f0 219       0.0509     cc1                      recog_2
0820c7f0 219       0.0509     cc1                      do_SUBST
080b5520 218       0.0507     cc1                      change_address_1
080b6f70 214       0.0498     cc1                      make_insn_raw
081e10b0 214       0.0498     cc1                      lookup_attribute
08072450 213       0.0495     cc1                      prep_stmt
08097210 212       0.0493     cc1                      remove_invalid_refs
00060d50 209       0.0486     libc.so.6                __find_specmb
08182370 206       0.0479     cc1                      alloc_INSN_LIST
0821e380 205       0.0477     cc1                      get_last_value_validate
00000000 205       0.0477     ld                       (no symbols)
0002d4e0 203       0.0472     libc.so.6                __GI___strtol_internal
08241510 203       0.0472     cc1                      build_insn_chain
081b5f20 202       0.0470     cc1                      finish_spills
081e1f30 202       0.0470     cc1                      compare_tree_int
0823a6a0 202       0.0470     cc1                      find_used_regs
000243f0 201       0.0468     libc.so.6                __dcigettext
081e0cf0 201       0.0468     cc1                      build_decl
0806c0b0 200       0.0465     cc1                      c_promoting_integer_type_p
081e1c40 200       0.0465     cc1                      tree_int_cst_sgn
08203d00 200       0.0465     cc1                      bitmap_initialize
080835c0 199       0.0463     cc1                      write_dependence_p
081824b0 199       0.0463     cc1                      free_INSN_LIST_list
080913b0 198       0.0461     cc1                      create_basic_block_structure
08170840 198       0.0461     cc1                      split_1
081efab0 197       0.0458     cc1                      clear_marks
080780f0 196       0.0456     cc1                      collect_args
080822b0 196       0.0456     cc1                      addr_side_effect_eval
080b6880 196       0.0456     cc1                      next_nonnote_insn
0810e170 193       0.0449     cc1                      get_attr_memory
081e12a0 193       0.0449     cc1                      get_qualified_type
0809f6e0 192       0.0447     cc1                      cse_main
080b3470 192       0.0447     cc1                      get_mem_attrs
08202630 191       0.0444     cc1                      ix86_register_move_cost
08219db0 191       0.0444     cc1                      num_sign_bit_copies
08261250 191       0.0444     cc1                      regmove_optimize
080a01c0 190       0.0442     cc1                      delete_trivially_dead_insns
080cf910 190       0.0442     cc1                      get_inner_reference
08185c20 190       0.0442     cc1                      requires_inout
080bc9e0 189       0.0440     cc1                      can_throw_internal
080ccb10 187       0.0435     cc1                      get_subtarget
080df670 186       0.0433     cc1                      invalidate_mems_from_set
081d6e10 186       0.0433     cc1                      finalize_type_size
080b3570 185       0.0430     cc1                      gen_rtx_CONST_INT
080f0460 185       0.0430     cc1                      combine_temp_slots
0821dbc0 185       0.0430     cc1                      record_value_for_reg
080ba3a0 184       0.0428     cc1                      remove_fixup_regions
0821e020 184       0.0428     cc1                      record_dead_and_set_regs
080f9960 183       0.0426     cc1                      mark_function_status
0819df10 183       0.0426     cc1                      extract_insn_cached
081c8880 183       0.0426     cc1                      simplify_relational_operation
081af320 181       0.0421     cc1                      find_equiv_reg
081b4dc0 181       0.0421     cc1                      check_eliminable_occurrences
0804fd10 177       0.0412     cc1                      lex_string
080b3d40 176       0.0409     cc1                      gen_lowpart_common
08054180 173       0.0402     cc1                      lookup_name
0805b940 173       0.0402     cc1                      lookup_field
08182160 173       0.0402     cc1                      lhd_tree_inlining_walk_subtrees
08183b20 173       0.0402     cc1                      block_alloc
081df8c0 172       0.0400     cc1                      build_tree_list
080cb4b0 171       0.0398     cc1                      emit_move_insn
08092760 170       0.0395     cc1                      tidy_fallthru_edge
081e1b90 170       0.0395     cc1                      tree_low_cst
08094f30 169       0.0393     cc1                      notreg_cost
08096340 169       0.0393     cc1                      lookup_for_remove
080ba500 169       0.0393     cc1                      remove_unreachable_regions
08095770 168       0.0391     cc1                      make_new_qty
081f3f90 168       0.0391     cc1                      ix86_address_cost
08202450 168       0.0391     cc1                      ix86_secondary_memory_needed
080f4e30 167       0.0388     cc1                      aggregate_value_p
08267bc0 167       0.0388     cc1                      sched_analyze_2
08082210 166       0.0386     cc1                      get_addr
0806e000 165       0.0384     cc1                      c_common_insert_default_attributes
08180a00 164       0.0381     cc1                      returnjump_p_1
080963e0 163       0.0379     cc1                      lookup_as_function
081ef400 163       0.0379     cc1                      ggc_collect
08181f90 161       0.0374     cc1                      true_regnum
081d7d30 161       0.0374     cc1                      ggc_alloc_string
080b83e0 159       0.0370     cc1                      start_sequence
080f77c0 159       0.0370     cc1                      prepare_function_start
08222c90 159       0.0370     cc1                      cselib_process_insn
08243090 159       0.0370     cc1                      schedule_insn
080b89d0 158       0.0368     cc1                      init_emit
081bfa40 158       0.0368     cc1                      shallow_copy_rtx
081ece70 156       0.0363     cc1                      mark_constants
080961e0 155       0.0361     cc1                      remove_from_table
081d1070 155       0.0361     cc1                      expand_start_bindings_and_block
08205f30 155       0.0361     cc1                      expunge_block
08208750 154       0.0358     cc1                      thread_jump
08078560 153       0.0356     cc1                      enter_macro_context
08092820 153       0.0356     cc1                      tidy_fallthru_edges
081c2f80 152       0.0354     cc1                      computed_jump_p_1
0823a2c0 152       0.0354     cc1                      compute_transp
081d1a60 151       0.0351     cc1                      expand_decl
08203410 151       0.0351     cc1                      bitmap_copy
081d16e0 150       0.0349     cc1                      expand_end_bindings
0805ca50 149       0.0347     cc1                      parser_build_binary_op
080e0d90 149       0.0347     cc1                      encode
08111830 149       0.0347     cc1                      get_attr_type
0817b750 149       0.0347     cc1                      save_for_inline
0823c370 148       0.0344     cc1                      delete_null_pointer_checks_1
0819f170 147       0.0342     cc1                      split_insn
081c2220 147       0.0342     cc1                      find_regno_note
0805fbd0 146       0.0340     cc1                      convert_for_assignment
081c3bc0 145       0.0337     cc1                      sbitmap_vector_alloc
0820d0c0 145       0.0337     cc1                      can_combine_p
00080720 144       0.0335     libc.so.6                __GI___mbrtowc
08096db0 144       0.0335     cc1                      check_dependence
080b39b0 144       0.0335     cc1                      gen_reg_rtx
081d92c0 144       0.0335     cc1                      check_global_declarations
081f71e0 143       0.0333     cc1                      ix86_expand_move
081a3370 141       0.0328     cc1                      record_address_regs
081e57e0 141       0.0328     cc1                      remap_block
08051980 140       0.0326     cc1                      pushlevel
081d8b20 140       0.0326     cc1                      floor_log2_wide
081e5650 140       0.0326     cc1                      remap_decl
0809af70 138       0.0321     cc1                      equiv_constant
08180910 138       0.0321     cc1                      any_uncondjump_p
0819d1c0 138       0.0321     cc1                      memory_address_p
0819df50 138       0.0321     cc1                      extract_constrain_insn_cached
080c2e30 137       0.0319     cc1                      expand_mult
080cb660 137       0.0319     cc1                      emit_move_insn_1
08091a70 136       0.0316     cc1                      merge_blocks_nomove
08170370 136       0.0316     cc1                      recog
081c2d40 136       0.0316     cc1                      replace_regs
080588d0 135       0.0314     cc1                      start_function
08182fb0 135       0.0314     cc1                      update_equiv_regs
0819cd10 135       0.0314     cc1                      immediate_operand
081e2d50 135       0.0314     cc1                      decl_function_context
082441f0 135       0.0314     cc1                      schedule_block
0000aed0 133       0.0309     libpthread.so.0          __pthread_alt_unlock
08051620 133       0.0309     gcc                      handle_braces
080de530 133       0.0309     cc1                      allocate_reg_life_data
0823f320 132       0.0307     cc1                      global_conflicts
0805a1e0 131       0.0305     cc1                      current_stmt_tree
08082060 131       0.0305     cc1                      base_alias_check
08238400 131       0.0305     cc1                      record_last_reg_set_info
08091360 130       0.0302     cc1                      delete_insn_chain
081b87a0 130       0.0302     cc1                      choose_reload_regs
08221320 130       0.0302     cc1                      clear_table
080dd800 129       0.0300     cc1                      calculate_global_regs_live
0810bcd0 129       0.0300     cc1                      function_units_used
081b2d30 129       0.0300     cc1                      order_regs_for_reload
081b40c0 129       0.0300     cc1                      eliminate_regs
08269500 129       0.0300     cc1                      free_deps
0001ee30 129       0.0300     libbfd-2.14.90.0.5.so    bfd_hash_lookup
08071920 128       0.0298     cc1                      build_stmt
080e0a90 128       0.0298     cc1                      count_or_remove_death_notes
0823d430 128       0.0298     cc1                      invalidate_any_buried_refs
0827fc00 128       0.0298     cc1                      splay_tree_lookup
0805c440 127       0.0295     cc1                      convert_arguments
081e2b40 127       0.0295     cc1                      int_fits_type_p
080da9e0 126       0.0293     cc1                      final_scan_insn
080e3a60 126       0.0293     cc1                      operand_equal_p
080b6050 124       0.0288     cc1                      unshare_all_rtl_1
08080c80 123       0.0286     cc1                      mems_in_disjoint_alias_sets_p
080f8ad0 123       0.0286     cc1                      prologue_epilogue_contains
080fc990 123       0.0286     cc1                      hook_tree_bool_false
081e6050 123       0.0286     cc1                      inlinable_function_p
0820c940 122       0.0284     cc1                      combine_instructions
00000000 122       0.0284     ISO8859-1.so             (no symbols)
08180940 121       0.0281     cc1                      any_condjump_p
080a0040 120       0.0279     cc1                      insn_live_p
080b6aa0 120       0.0279     cc1                      try_split
080e0dc0 120       0.0279     cc1                      decode
081b27b0 120       0.0279     cc1                      calculate_needs_all_insns
081b3600 120       0.0279     cc1                      find_reload_regs
081f3080 120       0.0279     cc1                      ix86_save_reg
08072810 119       0.0277     cc1                      c_cannot_inline_tree_fn
0809ea00 119       0.0277     cc1                      cse_process_notes
080b8050 119       0.0277     cc1                      emit_line_note
080ded60 119       0.0277     cc1                      init_propagate_block_info
081c1320 118       0.0274     cc1                      noop_move_p
0821be10 118       0.0274     cc1                      simplify_comparison
080720f0 117       0.0272     cc1                      genrtl_scope_stmt
080b8570 117       0.0272     cc1                      end_sequence
081d9a60 117       0.0272     cc1                      rest_of_compilation
0821a6d0 117       0.0272     cc1                      simplify_shift_const
08053ba0 116       0.0270     gcc                      validate_switches
0809b310 116       0.0270     cc1                      record_jump_cond
08180a70 116       0.0270     cc1                      onlyjump_p
0823f230 115       0.0267     cc1                      allocno_compare
00075930 114       0.0265     libc.so.6                _int_realloc
081e7ed0 114       0.0265     cc1                      make_decl_rtl
081f7500 114       0.0265     cc1                      ix86_expand_binary_operator
08054b60 113       0.0263     cc1                      start_decl
081bb300 113       0.0263     cc1                      emit_reload_insns
082211c0 113       0.0263     cc1                      new_elt_loc_list
080fa950 112       0.0261     cc1                      gen_rtx_fmt_e0
08217030 112       0.0261     cc1                      force_to_mode
082278d0 112       0.0261     cc1                      calc_idoms
08252130 112       0.0261     cc1                      find_single_use_in_loop
081b6530 111       0.0258     cc1                      scan_paradoxical_subregs
0827fa80 111       0.0258     cc1                      splay_tree_insert
0807a3b0 110       0.0256     cc1                      _cpp_parse_expr
08259420 110       0.0256     cc1                      canonicalize_condition
08221ce0 109       0.0254     cc1                      new_cselib_val
080bdcd0 108       0.0251     cc1                      plus_constant_wide
080fa410 108       0.0251     cc1                      gen_rtx_fmt_e
0817b680 108       0.0251     cc1                      copy_decl_for_inlining
081cf420 108       0.0251     cc1                      expand_expr_stmt_value
0820aa50 108       0.0251     cc1                      delete_unreachable_blocks
08242cb0 108       0.0251     cc1                      insn_cost
00023b50 107       0.0249     libc.so.6                __ctype_b_loc
081cef50 107       0.0249     cc1                      check_operand_nalternatives
081d54e0 107       0.0249     cc1                      mode_for_size
0805c090 106       0.0247     cc1                      build_external_ref
0808a330 106       0.0247     cc1                      special_function_p
08205ce0 106       0.0247     cc1                      free_edge
08205e10 106       0.0247     cc1                      alloc_block
08242dd0 106       0.0247     cc1                      priority
00026670 105       0.0244     libc.so.6                read_alias_file
080ccb50 105       0.0244     cc1                      expand_assignment
08222800 105       0.0244     cc1                      cselib_invalidate_rtx
080fb200 104       0.0242     cc1                      ggc_mark_rtvec_children
081c3c40 104       0.0242     cc1                      sbitmap_copy
081d5680 104       0.0242     cc1                      round_up
081ec1e0 104       0.0242     cc1                      free_varasm_status
0823fbf0 104       0.0242     cc1                      find_reg
080df590 104       0.0242     XFree86                  WaitForSomething
08072d90 103       0.0240     cc1                      skip_rest_of_line
080be3a0 103       0.0240     cc1                      memory_address
080dd2c0 103       0.0240     cc1                      delete_noop_moves
082228a0 103       0.0240     cc1                      cselib_record_set

[-- Attachment #3: 3.4 --]
[-- Type: text/plain, Size: 35203 bytes --]


CPU: CPU with timer interrupt, speed 1299.43 MHz (estimated)
Profiling through timer interrupt
vma      samples  %           app name                 symbol name
082138a0 14423     3.9552     cc1                      yyparse
0007ae60 9802      2.6880     libc.so.6                memset
082276e0 9071      2.4875     cc1                      _cpp_clean_line
0822e4a0 7632      2.0929     cc1                      ht_lookup
082b6fa0 7555      2.0718     cc1                      for_each_rtx
082c73a0 7222      1.9805     cc1                      ggc_alloc
0811e090 7018      1.9245     cc1                      htab_find_slot_with_hash
08228410 6523      1.7888     cc1                      _cpp_lex_direct
0823ca00 5627      1.5431     cc1                      cse_insn
082c3950 5604      1.5368     cc1                      make_node
000793f0 3964      1.0870     libc.so.6                strlen
08256c40 3842      1.0536     cc1                      mark_set_1
0829e560 3592      0.9850     cc1                      constrain_operands
082a5560 3366      0.9231     cc1                      reg_scan_mark_refs
00000000 3287      0.9014     as                       (no symbols)
00074fd0 3261      0.8943     libc.so.6                _int_malloc
082b71e0 3120      0.8556     cc1                      note_stores
00077d50 3095      0.8487     libc.so.6                index
08239a30 2934      0.8046     cc1                      fold_rtx
082c86a0 2736      0.7503     cc1                      ix86_decompose_address
08258100 2710      0.7432     cc1                      propagate_one_insn
082291b0 2586      0.7092     cc1                      cpp_get_token
082ccca0 2484      0.6812     cc1                      walk_tree
0821c6c0 2460      0.6746     cc1                      grokdeclarator
08239570 2349      0.6442     cc1                      canon_reg
0825c1b0 2314      0.6346     cc1                      fold
082a2a10 2307      0.6326     cc1                      record_reg_classes
08231800 2148      0.5890     cc1                      init_alias_analysis
00000000 2136      0.5858     gzip                     (no symbols)
0825a440 2136      0.5858     cc1                      force_fit_type
0007b5e0 2012      0.5517     libc.so.6                memcpy
08238060 2006      0.5501     cc1                      invalidate
082b73a0 1977      0.5422     cc1                      find_reg_note
08236ba0 1962      0.5380     cc1                      rtx_cost
08241550 1943      0.5328     cc1                      count_reg_usage
082aa6a0 1922      0.5271     cc1                      find_reloads
08227d30 1826      0.5007     cc1                      lex_identifier
08257bb0 1808      0.4958     cc1                      mark_used_regs
0811de00 1788      0.4903     cc1                      htab_expand
082bb140 1788      0.4903     cc1                      simplify_binary_operation
080df4d0 1771      0.4857     cc1                      rtx_equal_p
082321c0 1658      0.4547     cc1                      bitmap_set_bit
0825aab0 1653      0.4533     cc1                      int_const_binop
0829d130 1520      0.4168     cc1                      general_operand
08232500 1519      0.4166     cc1                      bitmap_bit_p
00077f20 1491      0.4089     libc.so.6                strcmp
08237860 1486      0.4075     cc1                      exp_equiv_p
0822f600 1466      0.4020     cc1                      canon_rtx
082b8a60 1447      0.3968     cc1                      commutative_operand_precedence
0823c1d0 1444      0.3960     cc1                      insert
08237360 1441      0.3952     cc1                      canon_hash
08219c10 1373      0.3765     cc1                      c_lex
0811e860 1360      0.3730     cc1                      splay_tree_splay_helper
00000000 1349      0.3699     make                     (no symbols)
0829dc60 1322      0.3625     cc1                      extract_insn
082c3870 1312      0.3598     cc1                      tree_size
08228f40 1301      0.3568     cc1                      _cpp_lex_token
08213520 1298      0.3559     cc1                      yylex
08236a50 1296      0.3554     cc1                      approx_reg_cost_1
082c9660 1295      0.3551     cc1                      legitimate_address_p
082a0d60 1277      0.3502     cc1                      init_regs
082cbbd0 1270      0.3483     cc1                      ix86_rtx_costs
082b8b50 1221      0.3348     cc1                      refers_to_regno_p
08236e90 1218      0.3340     cc1                      get_cse_reg_info
082a0930 1191      0.3266     cc1                      reg_class_subset_p
0822f3a0 1187      0.3255     cc1                      record_set
082e47e0 1162      0.3187     cc1                      reload_cse_simplify_operands
082c68f0 1151      0.3156     cc1                      et_splay
08243050 1148      0.3148     cc1                      cselib_process_insn
08242c00 1145      0.3140     cc1                      cselib_invalidate_regno
0825a950 1115      0.3058     cc1                      size_htab_eq
082576e0 1088      0.2984     cc1                      mark_used_reg
080489f0 1088      0.2984     fixdep                   parse_config_file
0828ece0 1074      0.2945     cc1                      mark_jump_label
08241fb0 1061      0.2910     cc1                      cselib_lookup
0829b760 1053      0.2888     cc1                      do_multiply
08230180 977       0.2679     cc1                      memrefs_conflict_p
0829df00 977       0.2679     cc1                      preprocess_constraints
0825a9a0 969       0.2657     cc1                      size_int_type_wide
00000000 960       0.2633     bash                     (no symbols)
082c3ed0 959       0.2630     cc1                      tree_cons
082325d0 935       0.2564     cc1                      bitmap_operation
082b7400 922       0.2528     cc1                      side_effects_p
0811e220 903       0.2476     cc1                      htab_find_slot
0826d7a0 902       0.2474     cc1                      find_loads
0822f700 897       0.2460     cc1                      rtx_equal_for_memref_p
082d39d0 887       0.2432     cc1                      nonzero_bits1
00007600 851       0.2334     ld-2.3.2.so              do_lookup_versioned
082388c0 820       0.2249     cc1                      mention_regs
082778a0 816       0.2238     cc1                      recog
082c3fc0 804       0.2205     cc1                      build1
0825a620 803       0.2202     cc1                      mul_double
0824a8f0 794       0.2177     cc1                      copy_rtx_if_shared_1
0825a910 793       0.2175     cc1                      size_htab_hash
082d1290 786       0.2155     cc1                      cleanup_cfg
082c1600 781       0.2142     cc1                      timevar_pop
08240b20 777       0.2131     cc1                      cse_basic_block
082c4540 763       0.2092     cc1                      is_attribute_p
000755e0 746       0.2046     libc.so.6                _int_free
082417c0 743       0.2038     cc1                      delete_trivially_dead_insns
08227bd0 731       0.2005     cc1                      _cpp_skip_block_comment
082a08a0 720       0.1974     cc1                      reg_classes_intersect_p
082c1510 711       0.1950     cc1                      timevar_push
0822fb50 707       0.1939     cc1                      find_base_term
0829b330 700       0.1920     cc1                      do_add
082b3f60 684       0.1876     cc1                      reload
082cb960 664       0.1821     cc1                      ix86_hard_regno_mode_ok
080df260 662       0.1815     cc1                      copy_rtx
08267700 662       0.1815     cc1                      size_binop
082b8f10 659       0.1807     cc1                      reg_overlap_mentioned_p
082406b0 656       0.1799     cc1                      cse_end_of_basic_block
082be150 652       0.1788     cc1                      simplify_plus_minus
082c91e0 646       0.1772     cc1                      ix86_delegitimize_address
082e1970 627       0.1719     cc1                      insn_extract
0826b320 612       0.1678     cc1                      find_used_regs
082b8150 605       0.1659     cc1                      volatile_refs_p
082da450 605       0.1659     cc1                      subst
00011410 603       0.1654     ld-2.3.2.so              strcmp
08219320 601       0.1648     cc1                      decl_attributes
0826db00 599       0.1643     cc1                      store_motion
0826b450 598       0.1640     cc1                      one_cprop_pass
08049338 595       0.1632     cc1                      anonymous symbol from section .plt
0829e480 591       0.1621     cc1                      reg_fits_class_p
082414f0 588       0.1612     cc1                      check_for_label_ref
082cfa90 587       0.1610     cc1                      find_basic_blocks
00074100 586       0.1607     libc.so.6                __malloc
08243c50 581       0.1593     cc1                      calculate_dominance_info
082309b0 579       0.1588     cc1                      nonoverlapping_memrefs_p
082eb710 569       0.1560     cc1                      sched_analyze_insn
000742d0 568       0.1558     libc.so.6                __cfree
0002ba00 562       0.1541     libc.so.6                __GI_getenv
082425c0 560       0.1536     cc1                      hash_rtx
00047c40 546       0.1497     libc.so.6                _IO_vfprintf_internal
0811dfa0 546       0.1497     cc1                      htab_find_with_hash
08231e10 545       0.1495     cc1                      bitmap_clear
082c4830 544       0.1492     cc1                      tree_int_cst_lt
082b75c0 543       0.1489     cc1                      set_noop_p
082a23e0 540       0.1481     cc1                      invalid_mode_change_p
000095d0 526       0.1442     ld-2.3.2.so              _dl_relocate_object_internal
0811dac0 520       0.1426     cc1                      hash_pointer
082385c0 520       0.1426     cc1                      lookup
08238ee0 519       0.1423     cc1                      insert_regs
082d6c30 519       0.1423     cc1                      combine_simplify_rtx
08237190 518       0.1421     cc1                      invalidate_for_call
0824d9c0 511       0.1401     cc1                      expand_expr_real
082d4360 511       0.1401     cc1                      cached_nonzero_bits
0822a570 507       0.1390     cc1                      _cpp_create_definition
082d5af0 490       0.1344     cc1                      make_compound_operation
08236240 488       0.1338     cc1                      convert_to_integer
082a5170 487       0.1335     cc1                      allocate_reg_info
082c41a0 479       0.1314     cc1                      build
082c3b10 475       0.1303     cc1                      copy_node
00074980 473       0.1297     libc.so.6                __calloc
0825a330 467       0.1281     cc1                      reg_set_to_hard_reg_set
082c5050 467       0.1281     cc1                      type_hash_eq
0824a7d0 453       0.1242     cc1                      reset_used_flags
08258db0 453       0.1242     cc1                      propagate_block
08242880 452       0.1240     cc1                      rtx_equal_for_cselib_p
082574d0 452       0.1240     cc1                      mark_set_regs
08227cd0 447       0.1226     cc1                      forms_identifier_p
00015b8f 446       0.1223     libc.so.6                __i686.get_pc_thunk.bx
08221940 437       0.1198     cc1                      build_binary_op
082243a0 437       0.1198     cc1                      convert
082cb3e0 432       0.1185     cc1                      ix86_memory_move_cost
00079600 427       0.1171     libc.so.6                strncmp
082c3c40 426       0.1168     cc1                      integer_zerop
08232080 424       0.1163     cc1                      bitmap_clear_bit
082c3db0 424       0.1163     cc1                      list_length
0826a800 423       0.1160     cc1                      compute_hash_table
080487f0 420       0.1152     fixdep                   is_defined_config
0002b6a0 419       0.1149     libc.so.6                msort_with_tmp
082b70a0 414       0.1135     cc1                      reg_mentioned_p
082b74c0 413       0.1133     cc1                      single_set_2
082566d0 411       0.1127     cc1                      insn_dead_p
08236b20 408       0.1119     cc1                      preferrable
082423e0 407       0.1116     cc1                      cselib_subst_to_values
082df580 405       0.1111     cc1                      schedule_block
000073c0 404       0.1108     ld-2.3.2.so              do_lookup
00075800 398       0.1091     libc.so.6                malloc_consolidate
08236f40 391       0.1072     cc1                      delete_reg_equiv
0829d420 391       0.1072     cc1                      register_operand
082d6ab0 391       0.1072     cc1                      check_promoted_subreg
082313d0 387       0.1061     cc1                      canon_true_dependence
082cd4c0 380       0.1042     cc1                      copy_body_r
082dca50 379       0.1039     cc1                      global_alloc
0829bab0 375       0.1028     cc1                      do_divide
0822a3c0 374       0.1026     cc1                      lex_expansion_token
082c6750 374       0.1026     cc1                      pool_alloc
082c18a0 369       0.1012     cc1                      check_global_declarations
08231e80 368       0.1009     cc1                      bitmap_copy
0829d760 368       0.1009     cc1                      nonimmediate_operand
082c3f80 364       0.0998     cc1                      first_rtl_op
082a4930 363       0.0995     cc1                      regclass
082b8000 359       0.0984     cc1                      find_reg_equal_equiv_note
082c47f0 355       0.0974     cc1                      tree_int_cst_sgn
0822ffa0 350       0.0960     cc1                      get_addr
0829afc0 350       0.0960     cc1                      sticky_rshift_significand
0829b1f0 350       0.0960     cc1                      normalize
0002dc10 345       0.0946     libc.so.6                __GI___strtoul_internal
0828eb20 345       0.0946     cc1                      pc_set
082c0970 341       0.0935     cc1                      layout_type
082b6aa0 338       0.0927     cc1                      rtx_varies_p
082a41b0 336       0.0921     cc1                      scan_one_insn
0829f5e0 335       0.0919     cc1                      validate_change
082bb010 330       0.0905     cc1                      avoid_constant_pool_reference
082c9410 329       0.0902     cc1                      ix86_find_base_term
08227680 325       0.0891     cc1                      add_line_note
0811ee70 324       0.0889     cc1                      splay_tree_compare_pointers
082300e0 324       0.0889     cc1                      addr_side_effect_eval
08267ad0 323       0.0886     cc1                      purge_addressof_1
0829d7d0 323       0.0886     cc1                      push_operand
082c7a60 323       0.0886     cc1                      ggc_alloc_zone
082a5ae0 322       0.0883     cc1                      reg_scan
08269010 321       0.0880     cc1                      contains
0006e560 320       0.0878     libc.so.6                _IO_new_file_xsputn
08267960 317       0.0869     cc1                      insns_for_mem_walk
082e6b90 317       0.0869     cc1                      find_matches
0821c030 315       0.0864     cc1                      finish_decl
08254e80 313       0.0858     cc1                      output_asm_insn
082af010 313       0.0858     cc1                      compute_use_by_pseudos
08110e70 311       0.0853     cc1                      try_combine
082907a0 307       0.0842     cc1                      local_alloc
08223340 305       0.0836     cc1                      default_conversion
0829f400 304       0.0834     cc1                      apply_change_group
00079710 303       0.0831     libc.so.6                strncpy
0829cfd0 300       0.0823     cc1                      asm_noperands
0822f000 298       0.0817     cc1                      find_base_value
0821ba50 296       0.0812     cc1                      pushdecl
082b9b70 296       0.0812     cc1                      uses_addressof
0824ad20 295       0.0809     cc1                      prev_real_insn
082d34f0 293       0.0803     cc1                      get_last_value_validate
0829d880 291       0.0798     cc1                      memory_operand
082c5630 289       0.0793     cc1                      int_fits_type_p
0821a380 287       0.0787     cc1                      poplevel
082c1e70 284       0.0779     cc1                      wrapup_global_declarations
08227e60 283       0.0776     cc1                      _cpp_get_fresh_line
082ce210 282       0.0773     cc1                      clear_decl_rtl
082cf470 282       0.0773     cc1                      control_flow_insn_p
082ce3f0 281       0.0771     cc1                      record_call_1
082b8b20 280       0.0768     cc1                      swap_commutative_operands_p
00007330 277       0.0760     ld-2.3.2.so              _dl_elf_hash
0829b110 276       0.0757     cc1                      lshift_significand
082a78c0 276       0.0757     cc1                      push_reload
0824a640 274       0.0751     cc1                      change_address_1
082ea880 271       0.0743     cc1                      add_dependence
08268610 270       0.0740     cc1                      instantiate_virtual_regs_1
08224b20 268       0.0735     cc1                      verify_tree
082bf0e0 268       0.0735     cc1                      layout_decl
08242e50 266       0.0729     cc1                      cselib_invalidate_mem
082c6f70 265       0.0727     cc1                      et_split
0007ad40 262       0.0718     libc.so.6                memmove
08236dc0 262       0.0718     cc1                      notreg_cost
0822a350 261       0.0716     cc1                      alloc_expansion_token
08269af0 260       0.0713     cc1                      expr_equiv_p
0007aed0 258       0.0708     libc.so.6                __GI___mempcpy
082590a0 258       0.0708     cc1                      update_life_info
0828f0c0 257       0.0705     cc1                      rebuild_jump_labels
082c8ba0 257       0.0705     cc1                      ix86_save_reg
0821b8a0 254       0.0697     cc1                      lookup_name
0824ace0 254       0.0697     cc1                      next_real_insn
080df430 253       0.0694     cc1                      shallow_copy_rtx
082b94d0 253       0.0694     cc1                      sbitmap_zero
082955f0 252       0.0691     cc1                      loop_optimize
082b77c0 252       0.0691     cc1                      note_uses
082e9b60 250       0.0686     cc1                      copyprop_hardreg_forward
08226920 249       0.0683     cc1                      _cpp_handle_directive
08236ae0 248       0.0680     cc1                      approx_reg_cost
0822fd90 247       0.0677     cc1                      base_alias_check
0828eb60 247       0.0677     cc1                      any_condjump_p
0823c9c0 246       0.0675     cc1                      invalidate_memory
082b0220 244       0.0669     cc1                      elimination_effects
082bd8f0 244       0.0669     cc1                      simplify_relational_operation
082c7a50 244       0.0669     cc1                      ggc_alloc_typed
0824ad60 240       0.0658     cc1                      active_insn_p
0811dad0 238       0.0653     cc1                      eq_pointer
082c3840 236       0.0647     cc1                      decl_assembler_name
082b0720 235       0.0644     cc1                      eliminate_regs_in_insn
082b1b30 235       0.0644     cc1                      reload_as_needed
08233040 233       0.0639     cc1                      find_unreachable_blocks
082c7f10 233       0.0639     cc1                      ggc_collect
082d4740 231       0.0633     cc1                      num_sign_bit_copies1
08241750 226       0.0620     cc1                      set_live_p
082b1370 226       0.0620     cc1                      finish_spills
082ccb90 223       0.0612     cc1                      copy_tree_r
082281d0 222       0.0609     cc1                      lex_number
0826ae10 220       0.0603     cc1                      compute_transp
00078c30 219       0.0601     libc.so.6                strcpy
08290470 217       0.0595     cc1                      alloc_INSN_LIST
082541e0 216       0.0592     cc1                      shorten_branches
082bfac0 215       0.0590     cc1                      place_field
082e6e50 215       0.0590     cc1                      regmove_optimize
00060d50 213       0.0584     libc.so.6                __find_specmb
0007b260 213       0.0584     libc.so.6                __GI___strcasecmp
082723e0 213       0.0584     cc1                      get_attr_memory
082198e0 212       0.0581     cc1                      split_specs_attrs
08256c00 209       0.0573     cc1                      invalidate_mems_from_autoinc
08258f80 209       0.0573     cc1                      count_or_remove_death_notes_bb
082c3d00 209       0.0573     cc1                      integer_onep
0823c8b0 208       0.0570     cc1                      invalidate_from_clobbers
082de7a0 208       0.0570     cc1                      priority
0823bec0 207       0.0568     cc1                      find_comparison_args
08242fd0 206       0.0565     cc1                      cselib_invalidate_rtx
082cd850 206       0.0565     cc1                      expand_call_inline
082cf3d0 205       0.0562     cc1                      inside_basic_block_p
08227980 204       0.0559     cc1                      _cpp_process_line_notes
08237120 204       0.0559     cc1                      remove_invalid_refs
0826a480 204       0.0559     cc1                      record_last_reg_set_info
08238640 203       0.0557     cc1                      lookup_as_function
0828a7b0 201       0.0551     cc1                      split_insns
0806a970 199       0.0546     cc1                      cpp_interpret_string
082d2a20 199       0.0546     cc1                      do_SUBST
08238730 198       0.0543     cc1                      rehash_using_reg
0829dec0 196       0.0537     cc1                      extract_insn_cached
082ba460 196       0.0537     cc1                      simplify_subreg
0822ac00 195       0.0535     cc1                      cpp_classify_number
000243f0 194       0.0532     libc.so.6                __dcigettext
0002d4e0 194       0.0532     libc.so.6                __GI___strtol_internal
08070ac0 194       0.0532     cc1                      expand_call
082905b0 191       0.0524     cc1                      requires_inout
082c4900 190       0.0521     cc1                      host_integerp
082d2ea0 190       0.0521     cc1                      mark_used_regs_combine
080895f0 187       0.0513     cc1                      synth_mult
08293b20 187       0.0513     cc1                      canonicalize_condition
08232d00 186       0.0510     cc1                      forwarder_block_p
082cb610 186       0.0510     cc1                      ix86_register_move_cost
082d6800 186       0.0510     cc1                      record_dead_and_set_regs
082dc760 186       0.0510     cc1                      build_insn_chain
08256b80 185       0.0507     cc1                      invalidate_mems_from_set
0822ec00 184       0.0505     cc1                      alias_sets_conflict_p
082422c0 183       0.0502     cc1                      cselib_lookup_mem
08269fa0 183       0.0502     cc1                      hash_scan_set
082b0630 182       0.0499     cc1                      check_eliminable_occurrences
00000000 182       0.0499     ld                       (no symbols)
0822b2b0 181       0.0496     cc1                      cpp_interpret_integer
0821ee50 177       0.0485     cc1                      start_decl
082d5310 175       0.0480     cc1                      if_then_else_cond
081081f0 174       0.0477     cc1                      force_to_mode
082d63f0 174       0.0477     cc1                      record_value_for_reg
0821f6a0 173       0.0474     cc1                      finish_struct
0826c800 173       0.0474     cc1                      invalidate_any_buried_refs
00080720 171       0.0469     libc.so.6                __GI___mbrtowc
08243840 171       0.0469     cc1                      calc_dfs_tree_nonrec
0828ef90 171       0.0469     cc1                      mark_all_labels
080df230 170       0.0466     cc1                      rtx_alloc
08239830 170       0.0466     cc1                      equiv_constant
0824aec0 170       0.0466     cc1                      add_insn
082cb000 170       0.0466     cc1                      ia32_use_dfa_pipeline_interface
08231580 168       0.0461     cc1                      write_dependence_p
082cb1e0 167       0.0458     cc1                      ix86_secondary_memory_needed
082c0590 164       0.0450     cc1                      finalize_type_size
0826d900 162       0.0444     cc1                      store_killed_in_insn
082b8570 160       0.0439     cc1                      replace_regs
0811ece0 159       0.0436     cc1                      splay_tree_lookup
082b7970 159       0.0436     cc1                      find_regno_note
082c5790 159       0.0436     cc1                      variably_modified_type_p
0811ef90 158       0.0433     cc1                      xcalloc
08219a20 158       0.0433     cc1                      cb_line_change
082c3eb0 158       0.0433     cc1                      build_tree_list
080dcc20 157       0.0431     cc1                      emit_reload_insns
082eadd0 157       0.0431     cc1                      sched_analyze_2
082c1750 156       0.0428     cc1                      floor_log2_wide
08084c20 155       0.0425     cc1                      set_mem_attributes_minus_bitpos
08241c50 154       0.0422     cc1                      new_elt_loc_list
08256420 152       0.0417     cc1                      allocate_reg_life_data
082940e0 152       0.0417     cc1                      loop_regs_scan
082c4e80 152       0.0417     cc1                      get_qualified_type
082ca8c0 152       0.0417     cc1                      ix86_adjust_cost
082cf5c0 152       0.0417     cc1                      make_edges
082d5050 152       0.0417     cc1                      cached_num_sign_bit_copies
00000000 152       0.0417     ISO8859-1.so             (no symbols)
080aacf0 151       0.0414     cc1                      recog_26
082c4630 151       0.0414     cc1                      lookup_attribute
08054610 150       0.0411     gcc                      validate_switches
0829d5c0 150       0.0411     cc1                      immediate_operand
082c90d0 150       0.0411     cc1                      ix86_address_cost
0811ef60 149       0.0409     cc1                      xmalloc
082c6430 149       0.0409     cc1                      mark_constants
082b93e0 145       0.0398     cc1                      sbitmap_vector_alloc
0826e980 144       0.0395     cc1                      gen_rtx_fmt_ee
0000aed0 143       0.0392     libpthread.so.0          __pthread_alt_unlock
080501b0 143       0.0392     cc1                      build_function_call
082369c0 143       0.0392     cc1                      fixed_base_plus_p
082ce280 143       0.0392     cc1                      eq_node
08232c60 142       0.0389     cc1                      bitmap_initialize
082a6680 142       0.0389     cc1                      find_equiv_reg
082d32f0 141       0.0387     cc1                      update_table_tick
082370d0 140       0.0384     cc1                      check_dependence
08241220 140       0.0384     cc1                      cse_main
08269300 140       0.0384     cc1                      alloc_gcse_mem
082c5240 140       0.0384     cc1                      compare_tree_int
08224030 138       0.0378     cc1                      parser_build_binary_op
082c5960 138       0.0378     cc1                      decode_reg_name
0826ef70 137       0.0376     cc1                      get_attr_type
0829f250 137       0.0376     cc1                      extract_constrain_insn_cached
082c71e0 137       0.0376     cc1                      et_set_father
0826a640 135       0.0370     cc1                      clear_modify_mem_tables
082ced30 135       0.0370     cc1                      unchecked_make_edge
0822ba20 134       0.0367     cc1                      _cpp_parse_expr
08269eb0 134       0.0367     cc1                      gcse_constant_p
082c4450 134       0.0367     cc1                      build_decl
082af1d0 133       0.0365     cc1                      scan_paradoxical_subregs
082c5940 133       0.0365     cc1                      strip_reg_name
08241e90 132       0.0362     cc1                      new_cselib_val
08079760 130       0.0356     cc1                      record_jump_cond
0810a810 130       0.0356     cc1                      simplify_shift_const
082311a0 129       0.0354     cc1                      true_dependence
08235b40 129       0.0354     cc1                      purge_dead_edges
08256a00 129       0.0354     cc1                      init_propagate_block_info
08268ed0 129       0.0354     cc1                      reorder_blocks_1
082c9ab0 128       0.0351     cc1                      constant_address_p
0824d2c0 127       0.0348     cc1                      protect_from_queue
08254a90 127       0.0348     cc1                      cleanup_subreg_operands
08225c40 126       0.0346     cc1                      c_promoting_integer_type_p
08228320 126       0.0346     cc1                      lex_string
082dad70 126       0.0346     cc1                      combine_instructions
0828fea0 125       0.0343     cc1                      true_regnum
08101cd0 123       0.0337     cc1                      hash_node
08053570 122       0.0335     gcc                      handle_braces
082bf080 122       0.0335     cc1                      round_up
081136c0 121       0.0332     cc1                      allocno_compare
08274860 121       0.0332     cc1                      function_units_used
082bef10 121       0.0332     cc1                      mode_for_size
0826c8a0 118       0.0324     cc1                      one_pre_gcse_pass
082af860 118       0.0324     cc1                      eliminate_regs
082b76d0 118       0.0324     cc1                      noop_move_p
082ecfd0 118       0.0324     cc1                      free_deps
08226200 117       0.0321     cc1                      c_estimate_num_insns_1
08233470 117       0.0321     cc1                      insn_locators_initialize
082a2540 116       0.0318     cc1                      record_address_regs
0825a420 114       0.0313     cc1                      decode
082900f0 114       0.0313     cc1                      compute_available
082a6370 114       0.0313     cc1                      operands_match_p
082c68a0 114       0.0313     cc1                      pool_free
0001ee30 114       0.0313     libbfd-2.14.90.0.5.so    bfd_hash_lookup
08226530 113       0.0310     cc1                      build_stmt
082554d0 113       0.0310     cc1                      final_scan_insn
0821f200 112       0.0307     cc1                      get_parm_info
0829d0f0 112       0.0307     cc1                      memory_address_p
00026670 111       0.0304     libc.so.6                read_alias_file
0828ebf0 111       0.0304     cc1                      any_uncondjump_p
082e1530 111       0.0304     cc1                      sched_init
08228180 109       0.0299     cc1                      _cpp_unaligned_alloc
08237820 109       0.0299     cc1                      safe_hash
08107b10 108       0.0296     cc1                      can_combine_p
0804c710 107       0.0293     gcc                      process_command
08290080 107       0.0293     cc1                      lhd_tree_inlining_auto_var_in_fn_p
00006d00 105       0.0288     libpthread.so.0          __GI___pthread_mutex_trylock
0824a420 105       0.0288     cc1                      gen_lowpart_common
082923f0 105       0.0288     cc1                      find_single_use_in_loop
0007ab80 104       0.0285     libc.so.6                __memchr
080c13d0 104       0.0285     cc1                      equiv_init_movable_p
0829f750 103       0.0282     cc1                      validate_replace_rtx_1
00023b50 102       0.0280     libc.so.6                __ctype_b_loc
00075930 102       0.0280     libc.so.6                _int_realloc
082b91b0 102       0.0280     cc1                      set_of_1
082c7df0 102       0.0280     cc1                      ggc_pop_context
00015f40 101       0.0277     libc.so.6                __GI___errno_location
0825b920 101       0.0277     cc1                      operand_equal_p
082a5f30 101       0.0277     cc1                      refers_to_regno_for_reload_p
082b9210 100       0.0274     cc1                      reg_referenced_p
082c3e40 100       0.0274     cc1                      chainon
0000b990 99        0.0271     ld-2.3.2.so              fixup
08236fe0 99        0.0271     cc1                      remove_from_table
0825a3f0 99        0.0271     cc1                      encode
0829fdd0 99        0.0271     cc1                      split_all_insns
082e5510 98        0.0269     cc1                      reload_cse_regs_1
0810c4f0 97        0.0266     cc1                      simplify_comparison
08223590 97        0.0266     cc1                      convert_for_assignment
082c5b30 97        0.0266     cc1                      make_decl_rtl
080df590 97        0.0266     XFree86                  WaitForSomething
08236e40 96        0.0263     cc1                      address_cost
0824ca20 96        0.0263     cc1                      can_throw_internal
08290440 96        0.0263     cc1                      free_list
082ce2a0 96        0.0263     cc1                      cgraph_node
082ead70 96        0.0263     cc1                      add_dependence_list_and_free
082403f0 95        0.0261     cc1                      cse_process_notes
082dc010 95        0.0261     cc1                      mark_reg_store
082af430 94        0.0258     cc1                      count_pseudo
082cc9f0 94        0.0258     cc1                      inline_forbidden_p_1
081047e0 93        0.0255     cc1                      reorder_basic_blocks
08243a80 93        0.0255     cc1                      assign_dfs_numbers
08249ee0 93        0.0255     cc1                      mem_attrs_htab_eq
08086e70 92        0.0252     cc1                      init_emit
082bea50 92        0.0252     cc1                      normalize
082bf780 92        0.0252     cc1                      normalize_offset
00000000 92        0.0252     nm                       (no symbols)
08065b00 91        0.0250     cc1                      expand_stmt
082c4d40 91        0.0250     cc1                      attribute_list_contained
082cd280 91        0.0250     cc1                      remap_type
080d0db0 89        0.0244     cc1                      estimate_probability
080bfd20 88        0.0241     cc1                      pre_edge_lcm

Re: gcc 3.5 integration branch proposal

[Nick Burrett]

Gabriel Dos Reis wrote:
> espie@quatramaran.ens.fr (Marc Espie) writes:
> 
> | I do see the benefits, sure (I love the new preprocessor, except for the
> | -traditional bug, and I really need a standard C++ compiler), but updating 
> | from 2.8.1 to 2.95 slowed our compiles by ~30%, and the on-going 2.95 to 
> | 3.3.2 update is slowing them by 30% more.    Heck, we do have
> | architectures that are NOT going to switch because the compile are
> | really too slow now.   There's even some chance only sparc64 will switch
> | because 2.95 was completely crap on sparc64 (understandably so).
> 
> We should probably require developers to use slow machines with small
> rams.  Semi ;-)

There's no harm in that.  I have a port of GCC 3.3.3 running on a 200MHz 
StrongARM that takes over 6 minutes to compile the following:

    #include <iostream>

    int main (void)
    {
      std::cout << "Hello World" << std::endl;
      return 0;
    }

GCC 2.95.4 compiled the same application on the same hardware in around 
20-30 seconds.

-- 
Nick Burrett
Network Engineer, Designer Servers Ltd.   http://www.dsvr.co.uk

Re: gcc 3.5 integration branch proposal

[Gabriel Dos Reis]

Steven Bosscher <stevenb@suse.de> writes:

| On Monday 19 January 2004 09:31, Gabriel Dos Reis wrote:
| > Steven Bosscher <stevenb@suse.de> writes:
| > | On Monday 19 January 2004 05:39, Gabriel Dos Reis wrote:
| > | > "Giovanni Bajo" <giovannibajo@libero.it> writes:
| > | > | Testcases would help. We seriously do care about all the compile-time
| > | > | regressions we have in bugzilla, but we have just a few of
| > | > | them. People should really file bugreports about it.
| > | >
| > | > Strongly seconded.  In private, I've told Marc that the more people
| > | > complain (i.e. filling reports) about their being bitten by
| > | > compile-time perforamnce, the more it is likely that GCC developers
| > | > will eventually care about it.
| > |
| > | Perhaps everyone has missed some of the work Honza has done this
| > | month to kill some of the most tough bottlenecks, and perhaps
| > | nobody has seen the numbers posted by Gerald that for his C++
| > | test case we _are_ much faster than 3.3 and 3.2?
| >
| > Don't be fooled.
| 
| I hope not to be.  But the numbers from this mail are encouraging:
| http://gcc.gnu.org/ml/gcc/2004-01/msg00670.html
| 
| Note that the message got zero follow-ups, which is surprising, at
| least, to me.

Let me clarify my previous message.

When I said "GCC developers will eventually care about it", I did not
mean to minimize or dismiss efforts of isolated individuals to speed
up the compiler.  However, I was referring to lack of general policy
along the lines that any patch more or less should be accompanied by
hard data showing its impact on the compile-time (yes, that is an
extreme statement  but I'm pretty sure you get the idea).  The
parallel model I have in mind is when -- long time ago, after repeated
mainline breakages for long periods -- we started requiring submitters
to clearly state on which plateforms they did bootstrap and reg-test 
the patched compiler.  From that point, it was clear that we were
taking "bootstrappable trees" seriously ;-)

-- Gaby

Re: gcc 3.5 integration branch proposal

[Steven Bosscher]

On Monday 19 January 2004 09:31, Gabriel Dos Reis wrote:
> Steven Bosscher <stevenb@suse.de> writes:
> | On Monday 19 January 2004 05:39, Gabriel Dos Reis wrote:
> | > "Giovanni Bajo" <giovannibajo@libero.it> writes:
> | > | Testcases would help. We seriously do care about all the compile-time
> | > | regressions we have in bugzilla, but we have just a few of
> | > | them. People should really file bugreports about it.
> | >
> | > Strongly seconded.  In private, I've told Marc that the more people
> | > complain (i.e. filling reports) about their being bitten by
> | > compile-time perforamnce, the more it is likely that GCC developers
> | > will eventually care about it.
> |
> | Perhaps everyone has missed some of the work Honza has done this
> | month to kill some of the most tough bottlenecks, and perhaps
> | nobody has seen the numbers posted by Gerald that for his C++
> | test case we _are_ much faster than 3.3 and 3.2?
>
> Don't be fooled.

I hope not to be.  But the numbers from this mail are encouraging:
http://gcc.gnu.org/ml/gcc/2004-01/msg00670.html

Note that the message got zero follow-ups, which is surprising, at
least, to me.

Gr.
Steven

Re: gcc 3.5 integration branch proposal

[Gabriel Dos Reis]

Steven Bosscher <stevenb@suse.de> writes:

| On Monday 19 January 2004 05:39, Gabriel Dos Reis wrote:
| > "Giovanni Bajo" <giovannibajo@libero.it> writes:
| > | Testcases would help. We seriously do care about all the compile-time
| > | regressions we have in bugzilla, but we have just a few of
| > | them. People should really file bugreports about it.
| >
| > Strongly seconded.  In private, I've told Marc that the more people
| > complain (i.e. filling reports) about their being bitten by
| > compile-time perforamnce, the more it is likely that GCC developers
| > will eventually care about it.
| 
| Perhaps everyone has missed some of the work Honza has done this
| month to kill some of the most tough bottlenecks, and perhaps
| nobody has seen the numbers posted by Gerald that for his C++
| test case we _are_ much faster than 3.3 and 3.2?

Don't be fooled.

-- Gaby

Re: gcc 3.5 integration branch proposal

[Steven Bosscher]

On Monday 19 January 2004 04:42, Marc Espie wrote:
> In fact, I finally got around to building gcc-head, and comparing it
> to gcc 3.3.2.
>
> To say that the results are disappointing would be an understatement:
>
> Time for a kernel compile, gcc 3.3.2:
>   276.63s real   193.01s user    26.86s system
> with gcc-head:
>   341.31s real   213.25s user    27.87s system
>
> Exact same options, basically -O2.

But not just -O2?  What exact flags did you use?

> Now, tell me again that GCC is getting faster...

You haven't said if you compiled with checking disabled or not.  On
gcc-head, the compiler builds with many sanity checks enabled by
default.  If you try the 3.4 branch, checking is disabled by default,
or you have to configure with --disable-checking.

If you have checking disabled, these numbers indeed are depressing.
But I assure you, there are people who _do_ care about compiler speed,
and bug reports with specific slowdowns for some input are really
welcome!

Thanks for bringing this up again.  I think it's really sad that so
many people stick with 2.95 because later GCCs are slower.

Gr.
Steven

Re: gcc 3.5 integration branch proposal

[Steven Bosscher]

On Monday 19 January 2004 05:39, Gabriel Dos Reis wrote:
> "Giovanni Bajo" <giovannibajo@libero.it> writes:
> | Testcases would help. We seriously do care about all the compile-time
> | regressions we have in bugzilla, but we have just a few of
> | them. People should really file bugreports about it.
>
> Strongly seconded.  In private, I've told Marc that the more people
> complain (i.e. filling reports) about their being bitten by
> compile-time perforamnce, the more it is likely that GCC developers
> will eventually care about it.

Perhaps everyone has missed some of the work Honza has done this
month to kill some of the most tough bottlenecks, and perhaps
nobody has seen the numbers posted by Gerald that for his C++
test case we _are_ much faster than 3.3 and 3.2?

Gr.
Steven

Re: gcc 3.5 integration branch proposal

[Andreas Jaeger]

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

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

>> Strongly seconded.  In private, I've told Marc that the more people
>> complain (i.e. filling reports) about their being bitten by
>> compile-time perforamnce, the more it is likely that GCC developers
>> will eventually care about it.
>
> It could also be nice to have a new document, linked to from the Projects 
> page ("Improve compilation speed" or something like that) which records the 
> various ideas people with a global view on the compiler think could lead to 
> this goal.  Rather semi-precise ideas than "Devise better data structures".

And that document should contain links to the PRs or testcases that we
have - like the famous bug report by Gerald ;-),

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: gcc 3.5 integration branch proposal

[Eric Botcazou]

> Strongly seconded.  In private, I've told Marc that the more people
> complain (i.e. filling reports) about their being bitten by
> compile-time perforamnce, the more it is likely that GCC developers
> will eventually care about it.

It could also be nice to have a new document, linked to from the Projects 
page ("Improve compilation speed" or something like that) which records the 
various ideas people with a global view on the compiler think could lead to 
this goal.  Rather semi-precise ideas than "Devise better data structures".

-- 
Eric Botcazou

Re: gcc 3.5 integration branch proposal

[Gabriel Dos Reis]

"Giovanni Bajo" <giovannibajo@libero.it> writes:

| Testcases would help. We seriously do care about all the compile-time
| regressions we have in bugzilla, but we have just a few of
| them. People should really file bugreports about it.

Strongly seconded.  In private, I've told Marc that the more people
complain (i.e. filling reports) about their being bitten by
compile-time perforamnce, the more it is likely that GCC developers
will eventually care about it. 

-- Gaby

Re: gcc 3.5 integration branch proposal

[Giovanni Bajo]

Marc Espie wrote:

> updating from 2.8.1 to 2.95 slowed our compiles by ~30%, and the
> on-going 2.95 to 3.3.2 update is slowing them by 30% more.

Testcases would help. We seriously do care about all the compile-time
regressions we have in bugzilla, but we have just a few of them. People should
really file bugreports about it.

> But seriously, the only claim of speed improvements I've seen that had
> any kind of foundation was the inline `improvement', where the current
> compiler as almost gone back to a par with the previous inlining
> speed, before it went from rtl to function-at-a-time.

GCC 3.4 is not that bad, it compiles much faster than 3.3 on several C++
testcases, especially with -O3 (thanks to unit-a-time). Try it.

Giovanni Bajo

Re: gcc 3.5 integration branch proposal

[Zack Weinberg]

espie@quatramaran.ens.fr (Marc Espie) writes:

> In fact, I finally got around to building gcc-head, and comparing it
> to gcc 3.3.2.
>
> To say that the results are disappointing would be an understatement:
>
> Time for a kernel compile, gcc 3.3.2:
>   276.63s real   193.01s user    26.86s system
> with gcc-head:
>   341.31s real   213.25s user    27.87s system
>
> Exact same options, basically -O2.

It would be useful if you could build profiled versions of both
compilers and report what that says for this test.  Or, if OpenBSD has
a system-wide profiler, use that.  Please do configure with
--disable-checking as mentioned downthread.

zw

Re: gcc 3.5 integration branch proposal

[David Edelsohn]

>>>>> Marc Espie writes:

Marc> In fact, I finally got around to building gcc-head, and comparing it
Marc> to gcc 3.3.2.

Marc> To say that the results are disappointing would be an understatement:

Marc> Time for a kernel compile, gcc 3.3.2:
Marc> 276.63s real   193.01s user    26.86s system
Marc> with gcc-head:
Marc> 341.31s real   213.25s user    27.87s system

Marc> Exact same options, basically -O2.

Marc> Now, tell me again that GCC is getting faster...

	Did you build head configured with --disable-checking?

David

RE: gcc 3.5 integration branch proposal

[Robert McNulty Junior]

Only on Faster Machines.
If you only build c and c++, then it seems fast on a lower 1.2 celeron.
If you use a Sparc or other CPU, where speeds are greater than 3 GB,
then sure, it seams fast. But it ain't. Only speedup is processor power.
Robert

-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
Marc Espie
Sent: Sunday, January 18, 2004 9:42 PM
To: gcc@gcc.gnu.org
Subject: Re: gcc 3.5 integration branch proposal

In fact, I finally got around to building gcc-head, and comparing it
to gcc 3.3.2.

To say that the results are disappointing would be an understatement:

Time for a kernel compile, gcc 3.3.2:
  276.63s real   193.01s user    26.86s system
with gcc-head:
  341.31s real   213.25s user    27.87s system

Exact same options, basically -O2.

Now, tell me again that GCC is getting faster...

Re: gcc 3.5 integration branch proposal

[Marc Espie]

In fact, I finally got around to building gcc-head, and comparing it
to gcc 3.3.2.

To say that the results are disappointing would be an understatement:

Time for a kernel compile, gcc 3.3.2:
  276.63s real   193.01s user    26.86s system
with gcc-head:
  341.31s real   213.25s user    27.87s system

Exact same options, basically -O2.

Now, tell me again that GCC is getting faster...

Re: gcc 3.5 integration branch proposal

[Gabriel Dos Reis]

espie@quatramaran.ens.fr (Marc Espie) writes:

| I do see the benefits, sure (I love the new preprocessor, except for the
| -traditional bug, and I really need a standard C++ compiler), but updating 
| from 2.8.1 to 2.95 slowed our compiles by ~30%, and the on-going 2.95 to 
| 3.3.2 update is slowing them by 30% more.    Heck, we do have
| architectures that are NOT going to switch because the compile are
| really too slow now.   There's even some chance only sparc64 will switch
| because 2.95 was completely crap on sparc64 (understandably so).

We should probably require developers to use slow machines with small
rams.  Semi ;-)

-- Gaby

Re: gcc 3.5 integration branch proposal

[Marc Espie]

In article <DD674EB8-460F-11D8-A1CA-0030657EA24A@apple.com> you write:
>I think that the release manager holding up GCC development for months 
>in order to achieve an arbitrary regression goal is inappropriate, 
>especially if this comes at the cost of other goals (most notably, 
>timeliness) of one or more releases.  In particular, I think that your 
>excessive focus on avoiding regressions is contributing to GCC's 
>serious problems in other areas, most notably speed of compilation and 
>speed of generated code when compared against the best available 
>commercial compilers (for me, that's CodeWarrior and icc/xlc 
>respectively, and we're about 60% and 25% behind respectively).

Speaking for various people in the OpenBSD project, the current
compiler speed is completely catastrophic.

What is very, very bad, is that I've seen wishful thinking messages
on this list that were announcing the speed issue was going to be taken
care of, but it didn't happen so far.

We are not following every release, and I am seeing increasing
reluctance wrt updating to a more recent version of GCC.

I do see the benefits, sure (I love the new preprocessor, except for the
-traditional bug, and I really need a standard C++ compiler), but updating 
from 2.8.1 to 2.95 slowed our compiles by ~30%, and the on-going 2.95 to 
3.3.2 update is slowing them by 30% more.    Heck, we do have
architectures that are NOT going to switch because the compile are
really too slow now.   There's even some chance only sparc64 will switch
because 2.95 was completely crap on sparc64 (understandably so).

And I still see absolutely NOTHING that shows that the
compile time is going to go down at some point in the future.
pre-compiled headers, tree-ssa,  all this are fine ideas, but judging
by past record,  I now seriously doubt that people who say GCC compile
time is going to improve are doing anything but selling a blatant lie.

I won't accuse them of doing that knowingly, of course.

But seriously, the only claim of speed improvements I've seen that had
any kind of foundation was the inline `improvement', where the current
compiler as almost gone back to a par with the previous inlining speed,
before it went from rtl to function-at-a-time.

This is more and more of a serious problem.

As a specific instance, I've been working on an attribute extension
that I had to port from 2.95 to 3.3.2, and I have real trouble seeing
how the `new' attribute infrastructure is an improvement on the old one.
The code isn't especially easier to read, and it replaces simple enums
with an attribute tree that gets parsed *each time* it's applied to a
node.

Sure, it's a tiny difference. But if a large part of the GCC development
consists of such tiny steps, well, it's not hard to say where the
compile time is going.

Re: gcc 3.5 integration branch proposal

[Andrew Haley]

Laurent GUERBY writes:
 > 13273 gcj regression from 3.3, assigned

and actively being worked on.

Andrew.

Re: gcc 3.5 integration branch proposal

[Laurent GUERBY]

On Wed, 2004-01-14 at 09:52, Steven Bosscher wrote:
> > To me, there are still too many regressions, some of which I view as
> > serious.  There are 18 wrong-code regressions, which I find particularly
> > worrisome.
> 
> There are just 13 wrong-code bugs in Bugzilla.  hpux is the biggest
> loser with three.  There also is one arm bug.  One of the other 9 is
> about -fwritable-strings.

And on the remaining 8, unless I'm mistaken, only three are present on
x86:

10684 also present in 3.2
11767 workaround from user: I removed -fnon-call-exceptions when building my code and it works as a workaround for me. 
13273 gcj regression from 3.3, assigned

Not that bad on the wrong-code side on one major platform.

Laurent

Re: gcc 3.5 integration branch proposal

[Mike Stump]

On Tuesday, January 13, 2004, at 05:35 PM, Joe Buck wrote:
> On Tue, Jan 13, 2004 at 03:29:12PM -0800, Mike Stump wrote:
>> Along these lines, I'd like to see C++ about 4x faster.  I'd be happy
>> with 2x faster[1], anything less, well, isn't interesting.  I'd like
>> for the SC to find and appoint such a person to tackle speed problems.
>
> Want the job? :-)

I'd happy to volunteer...  I'd be happy to have others do so as well, 
I'd be happy to have a couple of people listed...

> It's not like there is a paid position available.

My position isn't that of Tom Lord, :-)  but, what they are in a 
position to do is to find someone that will volunteer to be the 
maintainer for compilation speed for C++.  Part of that is to ensure 
that the compiler doesn't regress, part of that is to encourage others 
to consider compilation speed issues before it regresses, and the 
largest part would be rolling up the sleeves and doing the work.  By 
appoint, I merely meant bless to be the listed maintainer for such an 
issue.  I think we need more than just a few random people donating a 
few random patches to be able to approach a 4x speedup.

Let us know if such a position is to be created at this time, and who's 
on the hook for it...

Re: gcc 3.5 integration branch proposal

[Paul Koning]

>>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes:

 Geoff> Paul Koning <pkoning@equallogic.com> writes:
 >> >> * Correct code generation * Fewer ICEs * Standards conformance
 >> * >> Compilation speed * Performance * Features * Release
 >> frequency * >> Release timeliness
 >> >> 
 >> >> We need to figure out how to balance those goals better without
 >> >> losing ground in areas where we recently have been improving.
 >> 
 >> I can see why some of this ordering would be subject to
 >> disagreement, but I would hope that there also are partial
 >> orderings that are NOT debatable.
 >> 
 >> The general rule of software engineering is that correctness comes
 >> first, performance and schedule after that.

 Geoff> I don't believe that statement is correct as an absolute.

 Geoff> For instance, a product that never ships is *not* better than
 Geoff> a product that ships with bugs.  It is significantly worse.

 Geoff> Likewise, a product that is guaranteed to produce the correct
 Geoff> answer, but will take 400 years, is much worse than a product
 Geoff> that has a 99% chance of producing the correct answer in 10
 Geoff> minutes.

Depending on the mission, both of those statements are sometimes true
and sometimes completely false.  Consider safety-critical applications
-- flight control, pacemaker firmware, things like that...

Other applications aren't quite as stringent, but still, a lot have
quality requirements well above those of typical PC applications.
Consider a storage server device -- if you're storing data for
thousands of users, you have to take correctness VERY seriously if you
want to stay in business.  Shipping on schedule and then losing
customer data will not win you any friends at all.

   paul


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

Re: gcc 3.5 integration branch proposal

[Steven Bosscher]

> To me, there are still too many regressions, some of which I view as
> serious.  There are 18 wrong-code regressions, which I find particularly
> worrisome.

There are just 13 wrong-code bugs in Bugzilla.  hpux is the biggest
loser with three.  There also is one arm bug.  One of the other 9 is
about -fwritable-strings.

Gr.
Steven

Re: gcc 3.5 integration branch proposal

[Laurent GUERBY]

On Wed, 2004-01-14 at 07:13, Mark Mitchell wrote:
> We do still have quite a number of wrong-code regressions, and until
> recently we had a number of pretty serious rejects-valid bugs in the C++
> front end, at the very least.

One alternative to fixing is carefully documenting the known bugs,
their context, and possible workarounds in the release notes (if
the audit trail in bugzilla is convoluted post a summary
in bugzilla and copy it in the release notes).

Since free software bug chasing bounties seems to be fashionable
these days, may be then suggest to the generous donators to consider
those in GCC :).

Laurent

Re: gcc 3.5 integration branch proposal

[Laurent GUERBY]

On Wed, 2004-01-14 at 01:01, Geoff Keating wrote:
> For instance, a product that never ships is *not* better than a
> product that ships with bugs.  It is significantly worse.

Sure, better release a plane or car that crash down once every two
flights than not to release it at all.

Okay, people releasing planes are not supposed to trust blindly compiler
writers, and for good reasons when your message is taken into account,
it should be included in Software Engineering courses :).

> I don't believe that statement is correct as an absolute.

We're all in the relative :).

Laurent

Re: gcc 3.5 integration branch proposal

[Mark Mitchell]

> > By the way, there's no question that there will be chaos when we
> > finally
> > do branch, and everyone starts putting stuff in for 3.5.  That's
> > actually what's supposed to happen in Stage 1. :-)
>
> No, I don't think that is what's supposed to happen in Stage 1.  I
> certainly don't remember the word 'chaos' being used.

I agree; "chaos" was poor diction on my part.  But, Stage 1 is when we are
supposed to integrate new branches with major new functionality, and with
major new functionality we can expect some bugs.  So, I should perhaps have
said "instability" or just "more bugs".

> I think that the release manager holding up GCC development for months
> in order to achieve an arbitrary regression goal is inappropriate,
> especially if this comes at the cost of other goals (most notably,
> timeliness) of one or more releases.

I don't feel like I've been unilaterally obstructing a release.  I've been
doing what I perceived was desired, which was to avoid releasing a compiler
with lots of regressions.  It's possible that our priorities have changed,
or that I got it wrong -- but I think your language is a little strong.

We do still have quite a number of wrong-code regressions, and until
recently we had a number of pretty serious rejects-valid bugs in the C++
front end, at the very least.

You might have justifiably accused me of introducing a buggy new C++ parser.
:-)

> > We think that we will better serve the user community by making
> > releases somewhat more frequently, and on a consistent schedule.

It's funny that you quote these passage.  I wrote them. :-)  (Or, at least,
I wrote the original development plan document, which has been improved a
bit since then.)

I had to twist some arms on the SC to get us to agree to those goals -- 
there were people who wanted to downplay the scheduling aspect much more
heavily.

I've inentionally backed off the schedule goals in favor of the quality
goals; it didn't seem possible to achieve both.

I've aslo become more resistant to creating a release branch early on
because I've found that problems simply don't get fixed on the release
branch.  I could go ahead and spin releases, bugs and all, every so often; I
just don't feel that's in the best interest of our users.

> So, why do you think the current mainline is not "high quality"?

To me, there are still too many regressions, some of which I view as
serious.  There are 18 wrong-code regressions, which I find particularly
worrisome.

Obviously, that's a subjective judgement.

If the SC tells me to prioritize timeliness more heavily, I'll do that.

Would you like to send an email to the SC asking them if that's what they
want me to do, or would you prefer that I do it?

Thanks,

-- Mark

Re: gcc 3.5 integration branch proposal

[Joe Buck]

On Tue, Jan 13, 2004 at 03:29:12PM -0800, Mike Stump wrote:
> Along these lines, I'd like to see C++ about 4x faster.  I'd be happy 
> with 2x faster[1], anything less, well, isn't interesting.  I'd like 
> for the SC to find and appoint such a person to tackle speed problems.

Want the job? :-)

I would like C++ to be at least 2x faster too, but wanting it and making
it happen are two different things.  It's not like there is a paid
position available.

Re: gcc 3.5 integration branch proposal

[Andrew Pinski]

On Jan 13, 2004, at 16:47, Andrew Pinski wrote:

>
> On Jan 13, 2004, at 15:29, Mike Stump wrote:
>
>> On Tuesday, January 13, 2004, at 03:13 PM, Daniel Berlin wrote:
>>> Some of the problem is that we have people maintaining *large* 
>>> numbers of areas of the compiler
>>
>>> We need more people assigned (not more assignments for existing 
>>> people) to various areas of the compiler, who *want* to be [ ... ] 
>>> improving speed
>>
>> Along these lines, I'd like to see C++ about 4x faster.  I'd be happy 
>> with 2x faster[1], anything less, well, isn't interesting.  I'd like 
>> for the SC to find and appoint such a person to tackle speed 
>> problems.
>>
>> So far, it isn't happening...
>>
>>
>> 1 - Assumes no regressions...
>
>
> C++ has been improved for 3.4 compared to even 2.95.3.  One we are 
> more standards
> complaint.  Two, speed also has decreased (at least in the last three 
> days, mostly thanks
> to Jan Hubicka).  Optimization speed has also decreased also.  Looks 
> like you are
> volunteering for the position of speeding up C++.


Okay I am going to rewrite this one more time and try again at what I 
am really trying to
say.

Compile time speed has been decreased in the last three days, mostly 
thanks to Jan
Hubicka.  Jan is improving both speed of the compiler while optimizing 
and also with no
optimizations.  Also it looks like you are volunteering to help out, 
why do you not
propose a patch or two to help the effect here, I already posted some 
of my like six
months ago.

Thanks,
Andrew Pinski

Re: gcc 3.5 integration branch proposal

[Andrew Pinski]

On Jan 13, 2004, at 15:29, Mike Stump wrote:

> On Tuesday, January 13, 2004, at 03:13 PM, Daniel Berlin wrote:
>> Some of the problem is that we have people maintaining *large* 
>> numbers of areas of the compiler
>
>> We need more people assigned (not more assignments for existing 
>> people) to various areas of the compiler, who *want* to be [ ... ] 
>> improving speed
>
> Along these lines, I'd like to see C++ about 4x faster.  I'd be happy 
> with 2x faster[1], anything less, well, isn't interesting.  I'd like 
> for the SC to find and appoint such a person to tackle speed problems.
>
> So far, it isn't happening...
>
>
> 1 - Assumes no regressions...


C++ has been improved for 3.4 compared to even 2.95.3.  One we are more 
standards
complaint.  Two, speed also has decreased (at least in the last three 
days, mostly thanks
to Jan Hubicka).  Optimization speed has also decreased also.  Looks 
like you are
volunteering for the position of speeding up C++.


Thanks,
Andrew Pinski

Re: gcc 3.5 integration branch proposal

[Gabriel Dos Reis]

Geoff Keating <geoffk@geoffk.org> writes:

| Paul Koning <pkoning@equallogic.com> writes:
| 
| >  >> * Correct code generation * Fewer ICEs * Standards conformance *
| >  >> Compilation speed * Performance * Features * Release frequency *
| >  >> Release timeliness
| >  >> 
| >  >> We need to figure out how to balance those goals better without
| >  >> losing ground in areas where we recently have been improving.
| > 
| > I can see why some of this ordering would be subject to disagreement,
| > but I would hope that there also are partial orderings that are NOT
| > debatable. 
| > 
| > The general rule of software engineering is that correctness comes
| > first, performance and schedule after that.
| 
| I don't believe that statement is correct as an absolute.
| 
| For instance, a product that never ships is *not* better than a
| product that ships with bugs.  It is significantly worse.

Sure, but what is the relevance here?

I'm not convinced that your taking things to extreme will help your
cause; it will just have the effect of provoking negative reations.

-- Gaby

Re: gcc 3.5 integration branch proposal

[Geoff Keating]

Paul Koning <pkoning@equallogic.com> writes:

>  >> * Correct code generation * Fewer ICEs * Standards conformance *
>  >> Compilation speed * Performance * Features * Release frequency *
>  >> Release timeliness
>  >> 
>  >> We need to figure out how to balance those goals better without
>  >> losing ground in areas where we recently have been improving.
> 
> I can see why some of this ordering would be subject to disagreement,
> but I would hope that there also are partial orderings that are NOT
> debatable. 
> 
> The general rule of software engineering is that correctness comes
> first, performance and schedule after that.

I don't believe that statement is correct as an absolute.

For instance, a product that never ships is *not* better than a
product that ships with bugs.  It is significantly worse.

Likewise, a product that is guaranteed to produce the correct answer,
but will take 400 years, is much worse than a product that has a 99%
chance of producing the correct answer in 10 minutes.

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

Re: gcc 3.5 integration branch proposal

[Daniel Berlin]

> I'm going to avoid most of the issues raised so far and at least 
> comment
> on this:
>
> I've not seen in the years I've been working on gcc as few bugs as I
> currently see right now in mainline. I don't think quality has been
> higher. Mostly I think we've finally gotten people to do what we've 
> been
> complaining about over the years which is to file bugs when they run
> into them. Just look at the number of bugs we've gotten in the last,
> say, year or two compared with the number of bug reports from the last 
> 5
> before that.
>

Yup.
The quality of the bugs and the bug system is dramatically better than 
it was with GNATS.
:)
You can blame the high number of bugs on me then, i guess.

> -eric
>
> -- 
> Eric Christopher <echristo@redhat.com>
>

Re: gcc 3.5 integration branch proposal

[Eric Christopher]

> > These releases, however, are FSF releases, and they should be of the
> > same high quality as the FSF releases for other packages, such as Emacs
> > or GNU Awk.  Unless the SC says otherwise, of course. :-)
> 
> So, why do you think the current mainline is not "high quality"?

I'm going to avoid most of the issues raised so far and at least comment
on this:

I've not seen in the years I've been working on gcc as few bugs as I
currently see right now in mainline. I don't think quality has been
higher. Mostly I think we've finally gotten people to do what we've been
complaining about over the years which is to file bugs when they run
into them. Just look at the number of bugs we've gotten in the last,
say, year or two compared with the number of bug reports from the last 5
before that.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: gcc 3.5 integration branch proposal

[Michael Elizabeth Chastain]

David Edelsohn lists some priorities:

  * Correct code generation
  * Fewer ICEs
  * Standards conformance
  * Compilation speed
  * Performance
  * Features
  * Release frequency
  * Release timeliness

I would like to add:

  * Correct debug info generation

Michael C

Re: gcc 3.5 integration branch proposal

[Mike Stump]

On Tuesday, January 13, 2004, at 03:13 PM, Daniel Berlin wrote:
> Some of the problem is that we have people maintaining *large* numbers 
> of areas of the compiler

> We need more people assigned (not more assignments for existing 
> people) to various areas of the compiler, who *want* to be [ ... ] 
> improving speed

Along these lines, I'd like to see C++ about 4x faster.  I'd be happy 
with 2x faster[1], anything less, well, isn't interesting.  I'd like 
for the SC to find and appoint such a person to tackle speed problems.

So far, it isn't happening...


1 - Assumes no regressions...

Re: gcc 3.5 integration branch proposal

[Paul Koning]

 >> * Correct code generation * Fewer ICEs * Standards conformance *
 >> Compilation speed * Performance * Features * Release frequency *
 >> Release timeliness
 >> 
 >> We need to figure out how to balance those goals better without
 >> losing ground in areas where we recently have been improving.

I can see why some of this ordering would be subject to disagreement,
but I would hope that there also are partial orderings that are NOT
debatable. 

The general rule of software engineering is that correctness comes
first, performance and schedule after that.

In the list above, "correctness" covers the first three, but they are
not all the same.  In my view, correct code generation is vastly more
important than anything else.  After that comes fewer ICEs.  (ICEs are
a pain but if there's a workaround, you can still get your job done.
Bad code is much nastier because you may not realize you have a
problem to work around.)  As for standards conformance, I'm not sure
I'd even that high enough to have it trump some of the performance
things, but then again I'm not a language lawyer.

In any case, is there any disagreement that correct code generation is
absolutely the most important concern?  If so, why?

	   paul

Re: gcc 3.5 integration branch proposal

[Daniel Berlin]

> 	FSF GCC also has a very large and diverse user community who
> provide conflicting feedback about their priorities:
One way of gauging their feedback is to turn on the voting system in 
Bugzilla.
Since we have bugs for all of these things in Bugzilla, people can vote 
for the bugs that are most commiserate with their goals.
Of course, like all things, this is subject to it's own set of problems.
But right now, the only gauge we get is the mailing lists, and people's 
general feelings reviewing bug reports, neither of which is really 
quantifiable into a hard number we can look at :).


Of course, we could always turn it back off it it just seems to be a 
nuisance.

>
> * Correct code generation
> * Fewer ICEs
> * Standards conformance
> * Compilation speed
> * Performance
> * Features
> * Release frequency
> * Release timeliness
>
> 	We need to figure out how to balance those goals better without
> losing ground in areas where we recently have been improving.
>
Some of the problem is that we have people maintaining *large* numbers 
of areas of the compiler, but not fixing regressions (hopefully 
non-controversial) or improving code speed (this may be more 
controversial) in those areas.
That is, after all, part of being a maintainer. It's not just an 
honorary title.
We need more people assigned (not more assignments for existing people) 
to various areas of the compiler, who *want* to be fixing regressions 
and improving speed in various areas of the compiler.
And anyone who tries to argue we don't have the manpower to do this, is 
simply kidding themselves. These people certainly exist, and are, on 
this mailing list.
--Dan

Re: gcc 3.5 integration branch proposal

[David Edelsohn]

>>>>> Geoff Keating writes:

> Apple would like to use FSF releases.  Unfortunately, a prerequisite 
> for this is that the FSF actually makes releases in a timely fashion, 
> and this is not happening.

	I want to make sure that we distinguish between timely and
frequent.  I have received private feedback that vendors would appreciate
release dates that coincided better with a development plan schedule, but
they do not necessarily want more frequent releases than what we currently
are producing -- including the current slippage.  It's the inability of
vendors to plan any schedules around FSF GCC releases that is one of the
problems, IMHO.

	Most GCC developers work for vendors who have their own schedules
and own development priorities.  If FSF GCC's development process better
took those priorities into account, we might be able to get more help from
those vendors to produce timely releases.

	I previously have suggested defining feature goals for GCC
releases in conjunction with developers and vendors.  If vendors need a
feature in their own release, having that feature accepted and integrated
into FSF GCC would motivate them to use FSF GCC and work to have FSF GCC
released with that feature.

	We currently are spending so much time in feature-freeze mode and
leaving patches proposing new features unreviewed, that vendors have no
choice but to focus on their own source base.

	FSF GCC also has a very large and diverse user community who
provide conflicting feedback about their priorities:

* Correct code generation
* Fewer ICEs
* Standards conformance
* Compilation speed
* Performance
* Features
* Release frequency
* Release timeliness

	We need to figure out how to balance those goals better without
losing ground in areas where we recently have been improving.

David

Re: gcc 3.5 integration branch proposal

[Geoff Keating]

On Jan 12, 2004, at 3:49 PM, Mark Mitchell wrote:

> On Mon, 2004-01-12 at 15:42, Geoff Keating wrote:
>> On Jan 12, 2004, at 11:22 AM, Mark Mitchell wrote:
>>
>>> I'll make you a deal -- if you will commit to fixing five Bugzilla
>>> regressions between now and January 31st, and five more after the
>>> branch
>>> is made, then I'll create the branch on January 31st, come hell or 
>>> high
>>> water.  Deal?
>>
>> I think January 31 would be too long to wait, sorry.
>
> No counter-offer? :-)

I was going to, but it would have started with "Well, how about you 
create a branch two weeks ago, and then..."  :-)

> By the way, there's no question that there will be chaos when we 
> finally
> do branch, and everyone starts putting stuff in for 3.5.  That's
> actually what's supposed to happen in Stage 1. :-)

No, I don't think that is what's supposed to happen in Stage 1.  I 
certainly don't remember the word 'chaos' being used.

> I completely agree with Phil, however, that creating a proxy-mainline 
> is
> inappropriate.

I think that the release manager holding up GCC development for months 
in order to achieve an arbitrary regression goal is inappropriate, 
especially if this comes at the cost of other goals (most notably, 
timeliness) of one or more releases.  In particular, I think that your 
excessive focus on avoiding regressions is contributing to GCC's 
serious problems in other areas, most notably speed of compilation and 
speed of generated code when compared against the best available 
commercial compilers (for me, that's CodeWarrior and icc/xlc 
respectively, and we're about 60% and 25% behind respectively).

Just to remind you, here is a quote from our web pages:

> Although maintaining a development branch, including merging new 
> changes from the mainline, is somewhat burdensome, the absolute worst 
> case is that such a branch will have to be maintained for four months. 
> During two of those months, the only mainline changes will be 
> bug-fixes, so it is unlikely that many conflicts will occur.

Here's another one:

> We think that we will better serve the user community by making 
> releases somewhat more frequently, and on a consistent schedule.

I do not believe we are achieving this aim.

> Apple (and some other vendors, including CodeSourcery) is in the
> position of doing its own release management and bug-fixing based on
> various versions of GCC.  Therefore, having high-quality FSF releases
> may not make much of a difference to Apple; Apple doesn't use it
> directly anyhow.  (Of course I do not know what Apple's management 
> wants
> in this respect, nor do I know what your personal motivations might be,
> independently of your Apple employeeship.)

Apple would like to use FSF releases.  Unfortunately, a prerequisite 
for this is that the FSF actually makes releases in a timely fashion, 
and this is not happening.

> These releases, however, are FSF releases, and they should be of the
> same high quality as the FSF releases for other packages, such as Emacs
> or GNU Awk.  Unless the SC says otherwise, of course. :-)

So, why do you think the current mainline is not "high quality"?

-- 
Geoff Keating <geoffk@apple.com>

Re: gcc 3.5 integration branch proposal

[Gerald Pfeifer]

On Mon, 12 Jan 2004, Daniel Jacobowitz wrote:
> "Same high quality"?  I know you're aware of them, but you might want
> to revisit the reasons that _no vendor_ I know of in several years has
> shipped an FSF released compiler.

FreeBSD has been doing that more or less, and in some of the cases (like
SUSE last spring) there simply was a timing issue with the two release
schedules not fitting.

(We are not taking aboute a patch here or there, but substantial changes,
right?)

On Tue, 13 Jan 2004, Steven Bosscher wrote:
> Yes. Most of the RTL-opt branch is in SUSE's 3.3.3.  It is also on
> the hammer branch for everyone else.  Gentoo and Mandrake use the
> hammer branch, simply because it beats the FSF release on all turf.
> I still hope debian switches too, it would be a good choice I think.

With my FSF hat on, I don't like this too much.  With my distributor
hat on, I can fully understand it.  Long term, I hope we can converge
so that FSF GCC will be useful in a more direct way.

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

Re: gcc 3.5 integration branch proposal

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Everyone expects you to get releases out, but all you can actually do is
| prevent them from coming out. :-)

I very like this description ;-p

-- Gaby

Re: gcc 3.5 integration branch proposal

[Mark Mitchell]

> While I can't argue with the veracity of your claim, I must say I find
> it downright bizarre.  How can one oversee the productization of 
> something
> as complex as gcc without an understanding of -- and control over -- its
> architecture?  Unless, of course, productization is not in your job
> description either... :-)

I like to think my *understanding* is pretty good.

But, I don't have control.

Nobody at Red Hat, Apple -- or even general volunteers -- takes orders
from me.  We could organize GCC that way -- if it were thought to be a
good idea -- but most people don't think it's a good idea, and that's
not how it's organized.

My principle power is the power to say "no".  I can say "the release is
not ready", or "that patch cannot be checked in right now".  I can also
say "please help!".  But, I cannot say "fix that bug, you lousy weasel!"
or "get rid of reload!".

That's part of what makes being the RM hard. 

Everyone expects you to get releases out, but all you can actually do is
prevent them from coming out. :-)

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

Re: gcc 3.5 integration branch proposal

[Gabriel Dos Reis]

Ziemowit Laski <zlaski@apple.com> writes:

| The "language lawyer" argument is beside the point.  AltiVec is just
| one of many real-world, platform-specific C/C++ idiosyncracies out
| there.
| In my opinion, one of the duties of the RM (currently Mark) is to devise
| architectural solutions to accommodate such idiosyncracies in the same
| source base.  To the extent that he failed to do this,  Apple
| (and I suspect many others) wound up maintaining their own branches, and
| obviously have a lesser and lesser incentive to care about the quality
| of the mainline FSF product (which is where this discussion started).

I seriously suggest you talk with Matt Austern about this issue,
before you turn it into a discussion about individuals -- which I
guess, won't really help your cause.

-- Gaby

Re: gcc 3.5 integration branch proposal

[Ziemowit Laski]

On 12 Jan, 2004, at 17.01, Mark Mitchell wrote:

>> In my opinion, one of the duties of the RM (currently Mark) is to 
>> devise
>> architectural solutions to accommodate such idiosyncracies in the same
>> source base.
>
> This discussion is rapidly degenerating.
>
> Let's wrap it up and get back to work.
>
> For the record, though, I don't view it as part of my duties as RM to
> come up with any sort of design plans for GCC.  That would be fun, and
> it is in some other context's my job, and I suppose the FSF could
> conceivably appoint some kind of design planner, but they haven't, and
> if they did it might very well not be me!

While I can't argue with the veracity of your claim, I must say I find
it downright bizarre.  How can one oversee the productization of 
something
as complex as gcc without an understanding of -- and control over -- its
architecture?  Unless, of course, productization is not in your job
description either... :-)

> Somehow, we're taking in this down some route where it's Apple vs. the
> FSF, which is silly since I didn't criticize Apple.

I'm not arguing against anyone.  I was merely trying to explain why
people why not be as enthused about fixing remaining 3.4 bugs as you
might want them to be.

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

Re: gcc 3.5 integration branch proposal

[Jan Hubicka]

> "Same high quality"?  I know you're aware of them, but you might want
> to revisit the reasons that _no vendor_ I know of in several years has
> shipped an FSF released compiler. Even Debian, which is chronically
> short of the talented manpower required for compiler development, ships
> fifteen hundred lines of GCC patches plus a bleeding edge 3.3-cvs
> snapshot last I checked.  The people with real budgets, like SuSE and

I really tend to believe that hammer branch has possitive effect on FSF
release quality.  One thing SuSE can and FSF can't is to give patches
fair amount of testing.  Via Hammer branch many defects of
unit-at-a-time and profiling and other changes we do use were discovered
so it will hopefully make 3.4 easier to stabilize.

I really hope that when (if) 3.4 will be accepted for SuSE, I will be
able to throw 90% of the changes we have as they were in some form
merged into 3.4.  Location lists is last major change remaining.  I have
little understanding of this area, so can't really tell what is causing
it to be offending so much.
I plan to get deeper understanding once we will re-try send it for 3.5.

Honza
> Red Hat, have orders of magnitude more changes.
> 
> I suspect the primary users of the release tarballs are roll-your-own
> developers (mainly either embedded or need-a-newer-C++) and large site
> installations (universities, corporate, etc.) who have a stable
> existing OS with an older compiler.
> 
> Obviously we want higher quality releases.  But now that CodeSourcery
> is doing the exact same thing as all other vendors, I'm sure you can
> see why it happens, and holding off releases isn't going to help
> anything.  My utterly unqualified instinct says that postponing the
> release branch isn't going to help, since developers and vendors have
> absolutely demonstrated their willingness to work outside of the trunk.
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

Re: gcc 3.5 integration branch proposal

[Mark Mitchell]

> In my opinion, one of the duties of the RM (currently Mark) is to devise
> architectural solutions to accommodate such idiosyncracies in the same
> source base. 

This discussion is rapidly degenerating.  

Let's wrap it up and get back to work.

For the record, though, I don't view it as part of my duties as RM to
come up with any sort of design plans for GCC.  That would be fun, and
it is in some other context's my job, and I suppose the FSF could
conceivably appoint some kind of design planner, but they haven't, and
if they did it might very well not be me!

Somehow, we're taking in this down some route where it's Apple vs. the
FSF, which is silly since I didn't criticize Apple.  I'm not judgemental
about Apple's role; I'm merely pointing out that Apple's mindset and the
FSF's mindset might be different because they are looking for different
things from GCC.  That difference in mindset may lead to differences of
opinion about what actions should be taken in the FSF's GCC tree.

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

Re: gcc 3.5 integration branch proposal

[Ziemowit Laski]

On 12 Jan, 2004, at 16.45, Jan Hubicka wrote:

>> On Tuesday 13 January 2004 01:23, Ziemowit Laski wrote:
>>> On 12 Jan, 2004, at 16.18, Steven Bosscher wrote:
>>>> On Tuesday 13 January 2004 01:11, Ziemowit Laski wrote:
>>>>> On 12 Jan, 2004, at 15.49, Mark Mitchell wrote:
>>>>>> Apple (and some other vendors, including CodeSourcery) is in the
>>>>>> position of doing its own release management and bug-fixing based 
>>>>>> on
>>>>>> various versions of GCC.  Therefore, having high-quality FSF 
>>>>>> releases
>>>>>> may not make much of a difference to Apple; Apple doesn't use it
>>>>>> directly anyhow.
>>>>>
>>>>> And the reason we don't is because the FSF keeps shooting down our
>>>>> patches.
>>>>> You just can't have it both ways.
>>>>
>>>> And Apple keeps ignoring existing infrastructure.  I understand the
>>>> inconvenience for you, but you should _fix_ patches, not force in.
>>>
>>> Please explain what you mean by 'infrastucture' and just how evil 
>>> Apple
>>> is ignoring it.
>>
>> Not evil.  I never said that.  I wish I had an Apple.  Ask Pinski,
>> he knows ;-)
>>
>> What I mean is that most patches I've seen so far were shot down on
>> technical grounds, on bad timing (stage3), for not using existing
>> functions to perform certain actions (feedback-based prefetching),
>> apparently patents (?) for hot/cold, etc.
>
> One of causes of this is the fact that we happent to conflict in an
> efforts (prefetching, new inlining were both developed independently
> twice).  This is real shame as many of features Apple compiler has 
> would
> be very, very nice to have in mainline but merging is getting
> increasingly dificult.
> It would be great to simply use FSF CVS branch for Apple enhancements
> and post patches to gcc-patches as they are being developed or released
> to public.
>
> That would make it much easier to notice such an infrastructural
> conflicts much earlier.  I know I can watch Apple's CVS (is there some
> mainling list?) and I will try to do it in future, but it would be
> easier if this went in as other patches commonly do.

That's actually a very good point.  I'll forward this internally to the
powers that be for consideration.

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

Re: gcc 3.5 integration branch proposal

[Ziemowit Laski]

On 12 Jan, 2004, at 16.40, Steven Bosscher wrote:

> On Tuesday 13 January 2004 01:23, Ziemowit Laski wrote:
>> On 12 Jan, 2004, at 16.18, Steven Bosscher wrote:
>>> On Tuesday 13 January 2004 01:11, Ziemowit Laski wrote:
>>>> On 12 Jan, 2004, at 15.49, Mark Mitchell wrote:
>>>>> Apple (and some other vendors, including CodeSourcery) is in the
>>>>> position of doing its own release management and bug-fixing based 
>>>>> on
>>>>> various versions of GCC.  Therefore, having high-quality FSF 
>>>>> releases
>>>>> may not make much of a difference to Apple; Apple doesn't use it
>>>>> directly anyhow.
>>>>
>>>> And the reason we don't is because the FSF keeps shooting down our
>>>> patches.
>>>> You just can't have it both ways.
>>>
>>> And Apple keeps ignoring existing infrastructure.  I understand the
>>> inconvenience for you, but you should _fix_ patches, not force in.
>>
>> Please explain what you mean by 'infrastucture' and just how evil 
>> Apple
>> is ignoring it.
>
> Not evil.  I never said that.  I wish I had an Apple.  Ask Pinski,
> he knows ;-)
>
> What I mean is that most patches I've seen so far were shot down on
> technical grounds, on bad timing (stage3), for not using existing
> functions to perform certain actions (feedback-based prefetching),
> apparently patents (?) for hot/cold, etc.
>
>>  Also please explain how to fix patches that were shot
>> down _on principle_, such as my recent AltiVec work.
>
> That's a language issue that I have no opinion on other than that I
> think it would have been wise if Motorola had consulted language
> lawyers, but that's the past.  Others seem to have them.  Do you
> think branching 3.4 will suddenly make these people change their
> mind?

The "language lawyer" argument is beside the point.  AltiVec is just
one of many real-world, platform-specific C/C++ idiosyncracies out 
there.
In my opinion, one of the duties of the RM (currently Mark) is to devise
architectural solutions to accommodate such idiosyncracies in the same
source base.  To the extent that he failed to do this,  Apple
(and I suspect many others) wound up maintaining their own branches, and
obviously have a lesser and lesser incentive to care about the quality
of the mainline FSF product (which is where this discussion started).

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

Re: gcc 3.5 integration branch proposal

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| But, that doesn't alter the fact that my goal -- with my FSF RM hat on
| -- is to produce high-quality FSF releases, until or unless the FSF
| requests otherwise.

FWIW, I think it is a sensible and reasonable goal that the whole GCC
community should support instead of pushing for myriad of vendor
specific trees.  In the lon run, they tend to divise resources and
communities. 

--Ggaby

Re: gcc 3.5 integration branch proposal

[Daniel Jacobowitz]

On Mon, Jan 12, 2004 at 04:23:30PM -0800, Ziemowit Laski wrote:
> 
> On 12 Jan, 2004, at 16.18, Steven Bosscher wrote:
> 
> >On Tuesday 13 January 2004 01:11, Ziemowit Laski wrote:
> >>On 12 Jan, 2004, at 15.49, Mark Mitchell wrote:
> >>>Apple (and some other vendors, including CodeSourcery) is in the
> >>>position of doing its own release management and bug-fixing based on
> >>>various versions of GCC.  Therefore, having high-quality FSF releases
> >>>may not make much of a difference to Apple; Apple doesn't use it
> >>>directly anyhow.
> >>
> >>And the reason we don't is because the FSF keeps shooting down our
> >>patches.
> >>You just can't have it both ways.
> >
> >And Apple keeps ignoring existing infrastructure.  I understand the
> >inconvenience for you, but you should _fix_ patches, not force in.
> 
> Please explain what you mean by 'infrastucture' and just how evil Apple
> is ignoring it.  Also please explain how to fix patches that were shot
> down _on principle_, such as my recent AltiVec work.

That's the only patch I know of that was shot down on principle.  It
was shot down on the same principle the last time it was proposed, too,
so you can't really claim to be surprised!

And then bystanders gave you constructive comments on how to make it
much more non-intrusive, to the point where a revised patch might have
gotten a different reaction.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gcc 3.5 integration branch proposal

[Daniel Jacobowitz]

On Mon, Jan 12, 2004 at 04:28:50PM -0800, Joe Buck wrote:
> On Mon, Jan 12, 2004 at 07:05:54PM -0500, Daniel Jacobowitz wrote:
> > "Same high quality"?  I know you're aware of them, but you might want
> > to revisit the reasons that _no vendor_ I know of in several years has
> > shipped an FSF released compiler.
> 
> For this message I'm taking off the SC hat and putting on the corporate user
> hat.
> 
> My employer uses FSF-released compilers in preference to those
> vendor-hacked compilers to develop its commericial products.  That's
> because we can't have one GCC compiler for GNU/Linux and another one with
> a different set of bugs for Solaris, and because we usually need a newer
> compiler and an older OS version.

That's a good reason I hadn't considered.

> > Even Debian, which is chronically
> > short of the talented manpower required for compiler development, ships
> > fifteen hundred lines of GCC patches plus a bleeding edge 3.3-cvs
> > snapshot last I checked.
> 
> That's inaccurate in several respects.  First, Debian has not shipped
> yet; you are describing what is in their testing branch.  Second, most of
> the 1500 lines do not touch the gcc source itself, but create the
> Debian-specific files for their packaging system.  AFAIK, Debian is
> assuming that their 3.3-cvs compiler will correspond to 3.3.3 by the
> time sarge is shipped.  By doing what they are doing, the Debian people
> are finding bugs in 3.3.x that no one else is finding (thanks to their
> ports to platforms that would otherwise get little use).

No, that's incorrect on a few counts:
  - The last Debian release did the same thing.  Of course, that was
the 2.95 branch.
  - If history is any judge, Debian will end up staying with some
particular branch snapshot based on when every other piece of the
Debian release comes together.  There's only minor preference towards
release tarballs and at this date I don't think another bump is likely
before sarge.
  - I was only counting the patches to the source.  There's another
fifteen _thousand_ lines of assorted documentation and packaging.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gcc 3.5 integration branch proposal

[Jan Hubicka]

> On Tuesday 13 January 2004 01:23, Ziemowit Laski wrote:
> > On 12 Jan, 2004, at 16.18, Steven Bosscher wrote:
> > > On Tuesday 13 January 2004 01:11, Ziemowit Laski wrote:
> > >> On 12 Jan, 2004, at 15.49, Mark Mitchell wrote:
> > >>> Apple (and some other vendors, including CodeSourcery) is in the
> > >>> position of doing its own release management and bug-fixing based on
> > >>> various versions of GCC.  Therefore, having high-quality FSF releases
> > >>> may not make much of a difference to Apple; Apple doesn't use it
> > >>> directly anyhow.
> > >>
> > >> And the reason we don't is because the FSF keeps shooting down our
> > >> patches.
> > >> You just can't have it both ways.
> > >
> > > And Apple keeps ignoring existing infrastructure.  I understand the
> > > inconvenience for you, but you should _fix_ patches, not force in.
> >
> > Please explain what you mean by 'infrastucture' and just how evil Apple
> > is ignoring it.
> 
> Not evil.  I never said that.  I wish I had an Apple.  Ask Pinski,
> he knows ;-)
> 
> What I mean is that most patches I've seen so far were shot down on
> technical grounds, on bad timing (stage3), for not using existing
> functions to perform certain actions (feedback-based prefetching), 
> apparently patents (?) for hot/cold, etc.

One of causes of this is the fact that we happent to conflict in an
efforts (prefetching, new inlining were both developed independently
twice).  This is real shame as many of features Apple compiler has would
be very, very nice to have in mainline but merging is getting
increasingly dificult.
It would be great to simply use FSF CVS branch for Apple enhancements
and post patches to gcc-patches as they are being developed or released
to public.

That would make it much easier to notice such an infrastructural
conflicts much earlier.  I know I can watch Apple's CVS (is there some
mainling list?) and I will try to do it in future, but it would be
easier if this went in as other patches commonly do.

Honza
> 
> >  Also please explain how to fix patches that were shot
> > down _on principle_, such as my recent AltiVec work.
> 
> That's a language issue that I have no opinion on other than that I
> think it would have been wise if Motorola had consulted language
> lawyers, but that's the past.  Others seem to have them.  Do you
> think branching 3.4 will suddenly make these people change their
> mind?
> 
> Gr.
> Steven

Re: gcc 3.5 integration branch proposal

[Steven Bosscher]

On Tuesday 13 January 2004 01:23, Ziemowit Laski wrote:
> On 12 Jan, 2004, at 16.18, Steven Bosscher wrote:
> > On Tuesday 13 January 2004 01:11, Ziemowit Laski wrote:
> >> On 12 Jan, 2004, at 15.49, Mark Mitchell wrote:
> >>> Apple (and some other vendors, including CodeSourcery) is in the
> >>> position of doing its own release management and bug-fixing based on
> >>> various versions of GCC.  Therefore, having high-quality FSF releases
> >>> may not make much of a difference to Apple; Apple doesn't use it
> >>> directly anyhow.
> >>
> >> And the reason we don't is because the FSF keeps shooting down our
> >> patches.
> >> You just can't have it both ways.
> >
> > And Apple keeps ignoring existing infrastructure.  I understand the
> > inconvenience for you, but you should _fix_ patches, not force in.
>
> Please explain what you mean by 'infrastucture' and just how evil Apple
> is ignoring it.

Not evil.  I never said that.  I wish I had an Apple.  Ask Pinski,
he knows ;-)

What I mean is that most patches I've seen so far were shot down on
technical grounds, on bad timing (stage3), for not using existing
functions to perform certain actions (feedback-based prefetching), 
apparently patents (?) for hot/cold, etc.

>  Also please explain how to fix patches that were shot
> down _on principle_, such as my recent AltiVec work.

That's a language issue that I have no opinion on other than that I
think it would have been wise if Motorola had consulted language
lawyers, but that's the past.  Others seem to have them.  Do you
think branching 3.4 will suddenly make these people change their
mind?

Gr.
Steven

Re: gcc 3.5 integration branch proposal

[Joe Buck]

On Mon, Jan 12, 2004 at 07:05:54PM -0500, Daniel Jacobowitz wrote:
> "Same high quality"?  I know you're aware of them, but you might want
> to revisit the reasons that _no vendor_ I know of in several years has
> shipped an FSF released compiler.

For this message I'm taking off the SC hat and putting on the corporate user
hat.

My employer uses FSF-released compilers in preference to those
vendor-hacked compilers to develop its commericial products.  That's
because we can't have one GCC compiler for GNU/Linux and another one with
a different set of bugs for Solaris, and because we usually need a newer
compiler and an older OS version.

> Even Debian, which is chronically
> short of the talented manpower required for compiler development, ships
> fifteen hundred lines of GCC patches plus a bleeding edge 3.3-cvs
> snapshot last I checked.

That's inaccurate in several respects.  First, Debian has not shipped
yet; you are describing what is in their testing branch.  Second, most of
the 1500 lines do not touch the gcc source itself, but create the
Debian-specific files for their packaging system.  AFAIK, Debian is
assuming that their 3.3-cvs compiler will correspond to 3.3.3 by the
time sarge is shipped.  By doing what they are doing, the Debian people
are finding bugs in 3.3.x that no one else is finding (thanks to their
ports to platforms that would otherwise get little use).

> I suspect the primary users of the release tarballs are roll-your-own
> developers (mainly either embedded or need-a-newer-C++) and large site
> installations (universities, corporate, etc.) who have a stable
> existing OS with an older compiler.

We fall into the latter category, but it's common.

Corporations building product for GNU/Linux were until recently requiring
rather old configurations, like Red Hat 7.2 or 7.3 or Enterprise 2.1.
Products have long life cycles.  That means that we are typically using
a newer version of GCC than whatever the vendor shipped as part of the OS.
Given that GNU/Linux is only one of several targets, the existence of
Red Hat's "2.96" was pretty much ignored as a candidate for use, since it
did not exist as an option for Solaris, HP/UX, AIX, etc.  So, for us, what
the vendor shipped really did not matter all that much.

Re: gcc 3.5 integration branch proposal

[Ziemowit Laski]

On 12 Jan, 2004, at 16.18, Steven Bosscher wrote:

> On Tuesday 13 January 2004 01:11, Ziemowit Laski wrote:
>> On 12 Jan, 2004, at 15.49, Mark Mitchell wrote:
>>> Apple (and some other vendors, including CodeSourcery) is in the
>>> position of doing its own release management and bug-fixing based on
>>> various versions of GCC.  Therefore, having high-quality FSF releases
>>> may not make much of a difference to Apple; Apple doesn't use it
>>> directly anyhow.
>>
>> And the reason we don't is because the FSF keeps shooting down our
>> patches.
>> You just can't have it both ways.
>
> And Apple keeps ignoring existing infrastructure.  I understand the
> inconvenience for you, but you should _fix_ patches, not force in.

Please explain what you mean by 'infrastucture' and just how evil Apple
is ignoring it.  Also please explain how to fix patches that were shot
down _on principle_, such as my recent AltiVec work.

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

Re: gcc 3.5 integration branch proposal

[Steven Bosscher]

On Tuesday 13 January 2004 01:16, Daniel Jacobowitz wrote:
> Speaking just for myself, watching var-tracking not get reviewed
> repeatedly was a really depressing experience, since the patch
> motivated me to finish GDB support for the new debugging information.
> It's going to be a real user-visible quality-of-experience improvement
> when it goes in.  The longer Stage 3 drags on, the longer you have to
> use a SuSE (?) vendor compiler to get it.

Yes. Most of the RTL-opt branch is in SUSE's 3.3.3.  It is also on
the hammer branch for everyone else.  Gentoo and Mandrake use the
hammer branch, simply because it beats the FSF release on all turf.
I still hope debian switches too, it would be a good choice I think.

Gr.
Steven

Re: gcc 3.5 integration branch proposal

[Mark Mitchell]

On Mon, 2004-01-12 at 16:11, Ziemowit Laski wrote:
> On 12 Jan, 2004, at 15.49, Mark Mitchell wrote:
> 
> > Apple (and some other vendors, including CodeSourcery) is in the
> > position of doing its own release management and bug-fixing based on
> > various versions of GCC.  Therefore, having high-quality FSF releases
> > may not make much of a difference to Apple; Apple doesn't use it
> > directly anyhow.
> 
> And the reason we don't is because the FSF keeps shooting down our 
> patches.
> You just can't have it both ways.

I don't necessarily disagree.

But, that doesn't alter the fact that my goal -- with my FSF RM hat on
-- is to produce high-quality FSF releases, until or unless the FSF
requests otherwise.

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

Re: gcc 3.5 integration branch proposal

[Daniel Jacobowitz]

On Mon, Jan 12, 2004 at 07:05:54PM -0500, Daniel Jacobowitz wrote:
> "Same high quality"?  I know you're aware of them, but you might want
> to revisit the reasons that _no vendor_ I know of in several years has
> shipped an FSF released compiler. Even Debian, which is chronically
> short of the talented manpower required for compiler development, ships
> fifteen hundred lines of GCC patches plus a bleeding edge 3.3-cvs
> snapshot last I checked.  The people with real budgets, like SuSE and
> Red Hat, have orders of magnitude more changes.
> 
> I suspect the primary users of the release tarballs are roll-your-own
> developers (mainly either embedded or need-a-newer-C++) and large site
> installations (universities, corporate, etc.) who have a stable
> existing OS with an older compiler.
> 
> Obviously we want higher quality releases.  But now that CodeSourcery
> is doing the exact same thing as all other vendors, I'm sure you can
> see why it happens, and holding off releases isn't going to help
> anything.  My utterly unqualified instinct says that postponing the
> release branch isn't going to help, since developers and vendors have
> absolutely demonstrated their willingness to work outside of the trunk.

That message came out a whole lot meaner than appropriate.  I'd like to
apologize to Mark.  No one can dispute that we're doing a whole lot
better than we were before, and the quality of GCC releases is
improving.

However, extending Stage 3 to meet quality goals is not the way to
accomplish further improvement.  Especially not when we had some
high-profile problems with patches not getting reviewed at the end of
Stage 2.  I think we need to cut our losses and move on, and despite
the defeatist tone of the first third of this sentence, I think that
will still leave GCC 3.4 as an improvement.

Speaking just for myself, watching var-tracking not get reviewed
repeatedly was a really depressing experience, since the patch
motivated me to finish GDB support for the new debugging information. 
It's going to be a real user-visible quality-of-experience improvement
when it goes in.  The longer Stage 3 drags on, the longer you have to
use a SuSE (?) vendor compiler to get it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gcc 3.5 integration branch proposal

[Steven Bosscher]

On Tuesday 13 January 2004 01:11, Ziemowit Laski wrote:
> On 12 Jan, 2004, at 15.49, Mark Mitchell wrote:
> > Apple (and some other vendors, including CodeSourcery) is in the
> > position of doing its own release management and bug-fixing based on
> > various versions of GCC.  Therefore, having high-quality FSF releases
> > may not make much of a difference to Apple; Apple doesn't use it
> > directly anyhow.
>
> And the reason we don't is because the FSF keeps shooting down our
> patches.
> You just can't have it both ways.

And Apple keeps ignoring existing infrastructure.  I understand the
inconvenience for you, but you should _fix_ patches, not force in.

Gr.
Steven

Re: gcc 3.5 integration branch proposal

[Ziemowit Laski]

On 12 Jan, 2004, at 15.49, Mark Mitchell wrote:

> Apple (and some other vendors, including CodeSourcery) is in the
> position of doing its own release management and bug-fixing based on
> various versions of GCC.  Therefore, having high-quality FSF releases
> may not make much of a difference to Apple; Apple doesn't use it
> directly anyhow.

And the reason we don't is because the FSF keeps shooting down our 
patches.
You just can't have it both ways.

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

Re: gcc 3.5 integration branch proposal

[Daniel Jacobowitz]

On Mon, Jan 12, 2004 at 03:49:11PM -0800, Mark Mitchell wrote:
> On Mon, 2004-01-12 at 15:42, Geoff Keating wrote:
> > On Jan 12, 2004, at 11:22 AM, Mark Mitchell wrote:
> > 
> > > I'll make you a deal -- if you will commit to fixing five Bugzilla
> > > regressions between now and January 31st, and five more after the 
> > > branch
> > > is made, then I'll create the branch on January 31st, come hell or high
> > > water.  Deal?

All you're going to get from an offer like that is lower-quality bug
fixes.  It's not motivation, it's a deadline.

> > I think January 31 would be too long to wait, sorry.
> 
> No counter-offer? :-)
> 
> By the way, there's no question that there will be chaos when we finally
> do branch, and everyone starts putting stuff in for 3.5.  That's
> actually what's supposed to happen in Stage 1. :-)
> 
> I completely agree with Phil, however, that creating a proxy-mainline is
> inappropriate.
> 
> Apple (and some other vendors, including CodeSourcery) is in the
> position of doing its own release management and bug-fixing based on
> various versions of GCC.  Therefore, having high-quality FSF releases
> may not make much of a difference to Apple; Apple doesn't use it
> directly anyhow.  (Of course I do not know what Apple's management wants
> in this respect, nor do I know what your personal motivations might be,
> independently of your Apple employeeship.)
>   
> These releases, however, are FSF releases, and they should be of the
> same high quality as the FSF releases for other packages, such as Emacs
> or GNU Awk.  Unless the SC says otherwise, of course. :-)

"Same high quality"?  I know you're aware of them, but you might want
to revisit the reasons that _no vendor_ I know of in several years has
shipped an FSF released compiler. Even Debian, which is chronically
short of the talented manpower required for compiler development, ships
fifteen hundred lines of GCC patches plus a bleeding edge 3.3-cvs
snapshot last I checked.  The people with real budgets, like SuSE and
Red Hat, have orders of magnitude more changes.

I suspect the primary users of the release tarballs are roll-your-own
developers (mainly either embedded or need-a-newer-C++) and large site
installations (universities, corporate, etc.) who have a stable
existing OS with an older compiler.

Obviously we want higher quality releases.  But now that CodeSourcery
is doing the exact same thing as all other vendors, I'm sure you can
see why it happens, and holding off releases isn't going to help
anything.  My utterly unqualified instinct says that postponing the
release branch isn't going to help, since developers and vendors have
absolutely demonstrated their willingness to work outside of the trunk.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gcc 3.5 integration branch proposal

[Mark Mitchell]

On Mon, 2004-01-12 at 15:42, Geoff Keating wrote:
> On Jan 12, 2004, at 11:22 AM, Mark Mitchell wrote:
> 
> > I'll make you a deal -- if you will commit to fixing five Bugzilla
> > regressions between now and January 31st, and five more after the 
> > branch
> > is made, then I'll create the branch on January 31st, come hell or high
> > water.  Deal?
> 
> I think January 31 would be too long to wait, sorry.

No counter-offer? :-)

By the way, there's no question that there will be chaos when we finally
do branch, and everyone starts putting stuff in for 3.5.  That's
actually what's supposed to happen in Stage 1. :-)

I completely agree with Phil, however, that creating a proxy-mainline is
inappropriate.

Apple (and some other vendors, including CodeSourcery) is in the
position of doing its own release management and bug-fixing based on
various versions of GCC.  Therefore, having high-quality FSF releases
may not make much of a difference to Apple; Apple doesn't use it
directly anyhow.  (Of course I do not know what Apple's management wants
in this respect, nor do I know what your personal motivations might be,
independently of your Apple employeeship.)
  
These releases, however, are FSF releases, and they should be of the
same high quality as the FSF releases for other packages, such as Emacs
or GNU Awk.  Unless the SC says otherwise, of course. :-)

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

Re: gcc 3.5 integration branch proposal

[Zack Weinberg]

Geoff Keating <geoffk@apple.com> writes:

> On Jan 12, 2004, at 11:22 AM, Mark Mitchell wrote:
>
>> I'll make you a deal -- if you will commit to fixing five Bugzilla
>> regressions between now and January 31st, and five more after the
>> branch
>> is made, then I'll create the branch on January 31st, come hell or high
>> water.  Deal?
>
> I think January 31 would be too long to wait, sorry.

Why?

zw

Re: gcc 3.5 integration branch proposal

[Geoff Keating]

On Jan 12, 2004, at 11:22 AM, Mark Mitchell wrote:

> I'll make you a deal -- if you will commit to fixing five Bugzilla
> regressions between now and January 31st, and five more after the 
> branch
> is made, then I'll create the branch on January 31st, come hell or high
> water.  Deal?

I think January 31 would be too long to wait, sorry.

-- 
Geoff Keating <geoffk@apple.com>

Re: gcc 3.5 integration branch proposal

[Mike Stump]

On Saturday, January 10, 2004, at 07:41 AM, Phil Edwards wrote:
> No, I don't know that it's a viable solution, but I'd rather try to 
> fix the
> rules we've got than just do an end run around them.  Better 
> suggestions
> solicited.

If we had 0 regressions, then we'd not have these problems.  Only some 
of the people put in these regressions.  Not being able to have a place 
to check in development work is bad.  We want to freeze out new 
development work to try and encourage people to work on fixing 
regressions.

To me, the obvious conclusion would be to have a branch for new work 
that only people that don't have any regressions outstanding can check 
into.

Now, I don't know if that is a good idea or not, and I don't even know 
if it is possible due to an inability to know who caused the 
regression...  but, I thought I'd put it out there for people to ponder.

In time, with enough feedback, as a group, I suspect people would learn 
to introduce fewer regressions.

Re: gcc 3.5 integration branch proposal

[Mark Mitchell]

> I hope the rules can be fixed, to avoid these problems happening again 
> for 3.5.

I hear your pain, and I sympathize.

Believe me, I wish 3.4 were long since out the door.

The fundamental problem remains the following:

(1) Our very high rate of change, coupled with our relatively fragile
system, causes lots of regressions.

(2) We don't do a good job of making the people who caused the problems
fix them -- and sometimes they are unable to do so, for valid reasons. 
Sometimes we don't detect the problems quickly enough to figure out what
caused them easily.

(3) We have no dedicated bug-fixers, who simply treat fixing regressions
as their sole calling.  (I have actually been doing this for the C++
front end since the new parser went in; I've deliberately not worked on
a single piece of new functionality.)

My job here is to try to serve as best I can.  To me, the
regression-elimination goal has always been a good one; it's certainly
the one that I want most from the software I use.  But, if timeliness is
the imperative, I can manage the releases with that goal instead.  In
fact, that was my initial inclination -- but people resisted that
strategy somewhat strongly.

What's somewhat disappointing to me is that we clearly have the
resources to fix the regressions -- we just don't have the willingness. 
If every skilled GCC developer fixed four or five regressions, we'd have
zero open regressions at this point -- or, at least, the ones that were
open would be due to huge structural problems that we have no practical
way of fixing quickly.

I'll make you a deal -- if you will commit to fixing five Bugzilla
regressions between now and January 31st, and five more after the branch
is made, then I'll create the branch on January 31st, come hell or high
water.  Deal?

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

Re: gcc 3.5 integration branch proposal

[Geoffrey Keating]

On 10/01/2004, at 7:41 AM, Phil Edwards wrote:

> On Fri, Jan 09, 2004 at 04:47:05PM -0800, Geoffrey Keating wrote:
>> On 09/01/2004, at 4:25 PM, Phil Edwards wrote:
>>>
>>> This sounds no different than the normal trunk rules, and so it
>>> strikes me as
>>> just a bypass of the 3-stage rules so as to not wait for 3.4.  If
>>> there's
>>> a significant difference between these rules and the trunk rules, 
>>> then
>>> please explain what I've missed.  Otherwise I object, on the grounds
>>> that
>>> those rules are in place for a reason, and that deliberately 
>>> bypassing
>>> them instead of helping to get 3.4 branched does more harm than good.
>>
>> The significant difference is that this is not the trunk.
>
> That's a tautology, not an explanation.

It is not the trunk.  Therefore, it does not have any of the impacts on 
people working on GCC that it would have if it was the trunk.

>> Yes, this branch is being created because 3.4 is taking too long.  If
>> it was up to me, it would branch today and ship in two months exactly,
>> bugs or no bugs.
>
> And I largely agree with you.
>
>
>> in fact, if anyone had ever proposed that the
>> three-stage process should consist of an initial two-month stage 1,
>> then a four-month stage 2, then a six-month stage 3, I would have
>> objected greatly, on the grounds that such a release cycle is too long
>> and provides too little time for development.  (You'll recall that the
>> original proposal was for three two-month stages; at the time, I
>> thought that was a fair compromise.  It's a shame the compromise is 
>> not
>> being honoured.)
>
> No argument there.  So, let's fix that, rather than abandon it.  If we 
> get
> "this is exactly like the trunk, except it's not THE trunk, so we don't
> have to follow the rules" branches every time we're waiting to proceed
> from stage 3, then something is wrong.

I agree; something is wrong.  It was visible that something was wrong 
in the 3.3 timeframe, too.  Perhaps this time we will do something 
about it.

> What if there were a harder cap on the length of time we spend in a 
> stage?
> At the end of 2 months, we push hard to go to the next stage, after
> another month, if we're still not there, then too bad, we do it anyway.
> The "tough love" approach to release cycles.

I would support this, although I would prefer a hard cap of 2 months.  
IMO, if it's not fixed in 2 months it won't be fixed in 3.

> No, I don't know that it's a viable solution, but I'd rather try to 
> fix the
> rules we've got than just do an end run around them.  Better 
> suggestions
> solicited.

I hope the rules can be fixed, to avoid these problems happening again 
for 3.5.

Re: gcc 3.5 integration branch proposal

[Phil Edwards]

On Fri, Jan 09, 2004 at 04:47:05PM -0800, Geoffrey Keating wrote:
> On 09/01/2004, at 4:25 PM, Phil Edwards wrote:
> >
> >This sounds no different than the normal trunk rules, and so it 
> >strikes me as
> >just a bypass of the 3-stage rules so as to not wait for 3.4.  If 
> >there's
> >a significant difference between these rules and the trunk rules, then
> >please explain what I've missed.  Otherwise I object, on the grounds 
> >that
> >those rules are in place for a reason, and that deliberately bypassing
> >them instead of helping to get 3.4 branched does more harm than good.
> 
> The significant difference is that this is not the trunk.

That's a tautology, not an explanation.


> Yes, this branch is being created because 3.4 is taking too long.  If 
> it was up to me, it would branch today and ship in two months exactly, 
> bugs or no bugs.

And I largely agree with you.


> in fact, if anyone had ever proposed that the 
> three-stage process should consist of an initial two-month stage 1, 
> then a four-month stage 2, then a six-month stage 3, I would have 
> objected greatly, on the grounds that such a release cycle is too long 
> and provides too little time for development.  (You'll recall that the 
> original proposal was for three two-month stages; at the time, I 
> thought that was a fair compromise.  It's a shame the compromise is not 
> being honoured.)

No argument there.  So, let's fix that, rather than abandon it.  If we get
"this is exactly like the trunk, except it's not THE trunk, so we don't
have to follow the rules" branches every time we're waiting to proceed
from stage 3, then something is wrong.

What if there were a harder cap on the length of time we spend in a stage?
At the end of 2 months, we push hard to go to the next stage, after
another month, if we're still not there, then too bad, we do it anyway.
The "tough love" approach to release cycles.

No, I don't know that it's a viable solution, but I'd rather try to fix the
rules we've got than just do an end run around them.  Better suggestions
solicited.


Phil

-- 
=========0=========0=========0=========0=========0=========0=========0=========0

Re: gcc 3.5 integration branch proposal

[Geoffrey Keating]

On 09/01/2004, at 4:25 PM, Phil Edwards wrote:

> On Fri, Jan 09, 2004 at 04:11:39PM -0800, Geoffrey Keating wrote:
>> 1. This branch is for fully-tested, approved patches.  The rules for
>> committing to it are the same as the rules that apply during Stage 1 
>> of
>> GCC development.  Experimental or incomplete work should not be put on
>> the branch.
>> 2. The intention is that immediately after GCC 3.4 branches, this
>> branch will be merged back to mainline.
>> 3. I will be making regular (probably weekly) merges from mainline 
>> onto
>> this branch.  I will be testing these merges with a powerpc-darwin
>> native bootstrap.  Anyone who commits anything to the branch that 
>> can't
>> be fully tested with a powerpc-darwin native bootstrap should watch 
>> for
>> the mail I send out saying the merge is done, and then run a test on
>> their own platform and send the results to gcc-testresults.
>> 4. Anyone who commits to the branch is still responsible for
>> maintaining the patch on the branch: fixing regressions that it 
>> causes,
>> and sometimes updating or reintegrating it after merges.  I expect 
>> that
>> for most patches, this will be much less work than maintaining the
>> patch on their own.
>> 5. I may back a patch out of the branch if it (a) causes bootstrap
>> failure or significant regressions on any platform and the author
>> doesn't appear to be able to fix it quickly, or (b) don't appear to
>> have followed Rule 1 or Rule 3.
>
> This sounds no different than the normal trunk rules, and so it 
> strikes me as
> just a bypass of the 3-stage rules so as to not wait for 3.4.  If 
> there's
> a significant difference between these rules and the trunk rules, then
> please explain what I've missed.  Otherwise I object, on the grounds 
> that
> those rules are in place for a reason, and that deliberately bypassing
> them instead of helping to get 3.4 branched does more harm than good.

The significant difference is that this is not the trunk.

Yes, this branch is being created because 3.4 is taking too long.  If 
it was up to me, it would branch today and ship in two months exactly, 
bugs or no bugs.  I don't believe I ever signed up to a process where 
new GCC development would be halted for months in order to meet some 
arbitrary quality goal; in fact, if anyone had ever proposed that the 
three-stage process should consist of an initial two-month stage 1, 
then a four-month stage 2, then a six-month stage 3, I would have 
objected greatly, on the grounds that such a release cycle is too long 
and provides too little time for development.  (You'll recall that the 
original proposal was for three two-month stages; at the time, I 
thought that was a fair compromise.  It's a shame the compromise is not 
being honoured.)

Re: gcc 3.5 integration branch proposal

[Phil Edwards]

On Fri, Jan 09, 2004 at 04:11:39PM -0800, Geoffrey Keating wrote:
> 1. This branch is for fully-tested, approved patches.  The rules for 
> committing to it are the same as the rules that apply during Stage 1 of 
> GCC development.  Experimental or incomplete work should not be put on 
> the branch.
> 2. The intention is that immediately after GCC 3.4 branches, this 
> branch will be merged back to mainline.
> 3. I will be making regular (probably weekly) merges from mainline onto 
> this branch.  I will be testing these merges with a powerpc-darwin 
> native bootstrap.  Anyone who commits anything to the branch that can't 
> be fully tested with a powerpc-darwin native bootstrap should watch for 
> the mail I send out saying the merge is done, and then run a test on 
> their own platform and send the results to gcc-testresults.
> 4. Anyone who commits to the branch is still responsible for 
> maintaining the patch on the branch: fixing regressions that it causes, 
> and sometimes updating or reintegrating it after merges.  I expect that 
> for most patches, this will be much less work than maintaining the 
> patch on their own.
> 5. I may back a patch out of the branch if it (a) causes bootstrap 
> failure or significant regressions on any platform and the author 
> doesn't appear to be able to fix it quickly, or (b) don't appear to 
> have followed Rule 1 or Rule 3.

This sounds no different than the normal trunk rules, and so it strikes me as
just a bypass of the 3-stage rules so as to not wait for 3.4.  If there's
a significant difference between these rules and the trunk rules, then
please explain what I've missed.  Otherwise I object, on the grounds that
those rules are in place for a reason, and that deliberately bypassing
them instead of helping to get 3.4 branched does more harm than good.

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

gcc 3.5 integration branch proposal

[Geoffrey Keating]

It looks like it's going to be quite some time before 3.4 branches and 
the mainline is opened up for general work.  There are also a number of 
projects which are completed, or partially completed, and are waiting 
in branches and in people's private trees for 3.5 to open up to be 
committed.  This has a number of bad effects:

1. People are having to maintain their own patches and/or branches and 
keep them up-to-date.
2. These patches and branches are not getting as much testing as they 
might, because the available testing effort is being spread over many 
places.
3. These patches and branches are not being tested with each other.

I am concerned that this will cause great instability in the initial 
development of GCC 3.5, and will lead to delays in the release of GCC 
3.5.  I therefore propose to create a gcc-3.5-integration-branch.  It 
will be similar in some ways to the 'basic-improvement' branch in the 
GCC 3.4 timeframe, but will have some significant differences.  The 
proposed rules for the branch are:

1. This branch is for fully-tested, approved patches.  The rules for 
committing to it are the same as the rules that apply during Stage 1 of 
GCC development.  Experimental or incomplete work should not be put on 
the branch.
2. The intention is that immediately after GCC 3.4 branches, this 
branch will be merged back to mainline.
3. I will be making regular (probably weekly) merges from mainline onto 
this branch.  I will be testing these merges with a powerpc-darwin 
native bootstrap.  Anyone who commits anything to the branch that can't 
be fully tested with a powerpc-darwin native bootstrap should watch for 
the mail I send out saying the merge is done, and then run a test on 
their own platform and send the results to gcc-testresults.
4. Anyone who commits to the branch is still responsible for 
maintaining the patch on the branch: fixing regressions that it causes, 
and sometimes updating or reintegrating it after merges.  I expect that 
for most patches, this will be much less work than maintaining the 
patch on their own.
5. I may back a patch out of the branch if it (a) causes bootstrap 
failure or significant regressions on any platform and the author 
doesn't appear to be able to fix it quickly, or (b) don't appear to 
have followed Rule 1 or Rule 3.

Any objections to this proposal?  If not, I'll create the branch in the 
next few days.