Stange gcc 3.3 bug on Linux/ia64

[H. J. Lu]

On Tue, Jul 01, 2003 at 11:59:52PM -0700, Zack Weinberg wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > On Tue, Jul 01, 2003 at 11:19:44PM -0700, Zack Weinberg wrote:
> >> "H. J. Lu" <hjl@lucon.org> writes:
> >> 
> >> > I have a very strange gcc 3.3 bug on Linux/ia64. At random, I got
> >> > bootstrap failure:
> >> [...]
> >> 
> >> Interesting bug, but the patch you sent is fixing a non-bug, and one
> >> that could not cause the problem you see even if it were a bug.  You
> >> should be looking at the scheduler or the register allocator.
> >> 
> >> cpplib in 3.3 relies on documented and standardized behavior of mmap,
> >> which valgrind deliberately does not support because use of it is
> >> usually a bug.  Specifically, the memory between the end of a file
> >> that's been mmapped into memory, and the nearest higher page boundary,
> >> is guaranteed to be zero-filled by the kernel.  (In 3.4 we are no
> >
> > One mmap test in gcc 3.3 failed on Linux/ia64:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3163
> 
> That is anonymous mmap, which has nothing whatsoever to do with file
> mmap, and that test was broken anyway.
> 
> Zero-filling to the nearest page boundary is guaranteed by SUS, and to
> do anything else is a security hole.  (well, technically you could
> fill with truly random data to a page boundary, but why waste entropy
> like that?)
> 
> And if the kernel isn't holding up its end, what you would get is a
> syntax error, probably "stray '\xNN' in program".
> 

It is very strange indeed and may have something to do with preprocessor.
These are what I found so far:

1. It only happens when I use make to generate java/decl.o.
2. If I add -da to dump debug info in Makefile, the problem goes away.
3. If I use -E to preprocess java/decl.c first, the problem goes away.
4. The compiler also generates a few different debug statements for the
preprocessed input from the C input.



H.J.