Re: compile time regression, when adding cerr usage

[andre maute <andre dot maute at gmx dot de>]

On Tuesday 27 July 2004 02:57, you wrote:
> andre maute wrote:
> > when compiling the attached test file, you can see that the debugging
> > test needs
> > 	8 min!  with g++-3.4.1
> > Every other test including g++-3.3.3 needs only some seconds.
>
> We don't track bug reports sent to the gcc-bugs mailing list.  If you
> want something done about this, you should file a bug report into our
> bugzilla bug database.

i already did that, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16613

>
> I took a quick look at this.  You are using -O3 which enables
> -finline-functions.  The presense of the iostreams code causes gcc to

-fininline-functions is enabled in -O3 for both gcc-3.3.3 and gcc-3.4.1

> make different decisions about function inlining and optimization, and
> the code size blows up.  The .s file is almost 7 times as big when the
> debugging code is included.  So the file takes so much longer to compile
> just because there is so much more code.
but not with gcc-3.3.3

> Part of the issue here might be that the debugging code is confusing the
> gcc optimizer.  It occurs between where the arrays are declared and
> where they are used.
Sorry that's wrong, cerr is declared at the beginning of the file and used at 
the end of the file.

> Maybe there is an aliasing problem, or something, 
> that is causing some optimization to be missed, that ordinarily would
> prevent the code size from blowing up.  I didn't bother looking into
> this though.  All I did was reproduce the problem.

Regards
Andre Maute