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

[Mark Grosberg]

On Mon, 28 Feb 2000, Horst von Brand 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. 
> 
> gcc -E takes a few seconds to generate the 12Mb output on my PC, so it is
> probably not hanging in preprocessing. AFAIU, CPP is now integrated into
> the lexical analysis of CC1, so there isn't a clearcut difference anymore.

I was doing ths on a pretty fast PowerPC system though. And I still do see
a cpp and a cc1... Is the cpp just a dummy now?
 
> > Recursive macro definitions should be caught, no? 
> 
> is happening in your case is that you have strcpy()'s #define checking for
> different conditions (constant source, known length, whatever) and doing

That does seem to be the case.

> different things in the different cases. Now you are placing strcpy()s in
> them, which get expanded in turn, probably several times in each case. Thus
> the immense .i file, and the resulting enormous forest of conditions takes
> a huge ammount of memory to compile. Maybe if you give it enough RAM and
> time it will go through.

That is what other people on the list have found (I don't have enough swap
disk on any of my boxes to try it my self). 

So is this still considered a GCC bug or is it a GLIBC bug? If it is a
GLIBC bug, can anybody direct me to where I can submit a bug report?

Unless GCC is made to deal with intrinsics internally, I would say this is
more a GLIBC bug. 

Thanks,
Mark G.