I think I found a bug in the optimizer...

[Mark Grosberg]

On Sun, 27 Feb 2000, Zack Weinberg wrote:

> > Although, it seems to be CPP, not CC1 that is having fits. This would lead
> > me to suspect that there is a bug in CPP that glibc is bringing out. 
> 
> No, it's definitely cc1.  I can reproduce this quite easily on my
> system.  It's just tied into knots building a parse tree for this
> monster expression.  We don't ever even get to rest_of_compilation.

Well. Then we may have two seperate bugs here. When I run this on my
PowerPC compiler, I get the following:

USER    PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
myg     966  7.6 34.0 141224 32392 pts/2  T    02:23   0:06 egcs-2.91.66/cpp 
myg     967  0.0  0.3  3676  304 pts/2    T    02:23   0:00 egcs-2.91.66/cc1
myg     968  0.0  0.4  2924  440 pts/2    T    02:23   0:00 as -mppc -Qy

I re-formatted this a little better to fit. But, as you can see, cpp is
taking up a lot of memory and cc1 isn't using very much VM at all.

I was using:

 [myg] pie:/vg/0/projects/amc/src/system>gcc --version
 egcs-2.91.66
 [myg] pie:/vg/0/projects/amc/src/system>uname -a
 Linux pie.nolab.conman.org 2.2.1 #101 Fri Feb 5 16:17:12 EST 1999 ppc unknown

... by the way. 
 
> > Recursive macro definitions should be caught, no? 
> 
> It's a perfectly legitimate nested macro.

It seems to be overkill for strcpy() to me. I could almost understand
memcpy(), but strcpy(), that's usually for small strings. And even for
large strings, doing all that extra work doesn't seem like it would be
that much of a big win.
 
> I've thought for a long time that glibc's string inlines were evil;
> they can double your executable size, and I've never seen them give a
> performance improvement.  You can turn them off with -D__NO_STRING_INLINES,
> or compile with -Os instead of -O2.

I saw that. I just changed the offending code and it compiles and works
now. I'm quite surprised that the intrinsics aren't implemented like GCC
implements alloca() (__builtin_alloca). You could probably get more
semantic information that way anyhow (but it would complicate the compiler
more)...

L8r,
Mark G.