Stange gcc 3.3 bug on Linux/ia64

[H. J. Lu]

On Wed, Jul 02, 2003 at 04:35:36PM -0700, H. J. Lu wrote:
> 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.
> 
> 

It got stranger and stranger. I created a small Makefile to recreate
the problem. If I comment out 

PWD = $${PWDCMD-pwd}

the bug doesn't show up.


H.J.
-----
PWD = $${PWDCMD-pwd}
GCC-SRC-DIR=/net/gnu/export/gnu/src/gcc-3.3-redhat/gcc/gcc
GCC-DIR=/export/build/gnu/gcc-3.3-redhat/build-ia64-linux/gcc
CFLAGS=-B/usr/gcc-3.3-redhat/ia64-unknown-linux-gnu/bin/ \
	 -g -O2 -DIN_GCC  -W -Wall -Wwrite-strings \
	 -Wstrict-prototypes -Wmissing-prototypes \
	 -DHAVE_CONFIG_H  -I. -Ijava \
	 -I$(GCC-SRC-DIR) \
	 -I$(GCC-SRC-DIR)/java \
	 -I$(GCC-SRC-DIR)/config \
	 -I$(GCC-SRC-DIR)/../include

bad:
	stage2/xgcc -Bstage2/ -S $(CFLAGS) $(GCC-SRC-DIR)/java/decl.c
	diff -up decl.s foo.s | grep "(p"