This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [GCC 3.0] Bad regression, binary size
- To: gcc at gcc dot gnu dot org
- Subject: Re: [GCC 3.0] Bad regression, binary size
- From: Marc Espie <espie at quatramaran dot ens dot fr>
- Date: Mon, 9 Jul 2001 09:06:50 +0200
- Organization: Ecole Normale Superieure (quatramaran)
In article <20010705154207.74D63F2B5E@nile.gnat.com> you write:
><<This is a significant regression from 2.95.2. Fortunately, it does seem to
>come from some linker issue which I hope to figure out, but be assured this
>kind of problem is very serious.
>I really can't agree that a 2% difference in object size is a significant
>regression. Optimization is a trade off between size and execution speed,
>and you may well get variations in this range from one version of a compiler
>to another.
<devil's advocate>
Err... New compilers are supposed to be BETTER than old ones. Ideally, there
should be no regression at all ! What's the damn point of -Os if successive
releases of the compiler keep getting out larger and larger code ?
In fact, what's the point of adding and adding more optimizing passes to
the compiler if all it does is keep the code size mostly identical, keep
the running time mostly identical, and slow the compiler down even more ?
And I'm not even talking some obscure, half-supported platform like m68k,
which has had ICEs every new release since 2.8, but i386...
One issue is that updating is necessary to get work-in-progress progress
on real important things, like C++ support. Why does this have to come
with plain old C regressions ?
</devil's advocate>
In fact, as I stated already, this seems to be a weird linker/compiler
interaction, which I'm going to try to figure out.