Re: gcc 3.5 integration branch proposal

[espie@quatramaran.ens.fr (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.