--- Additional Comments From sampo at symlabs dot com 2004-11-23 02:49
---
This bug should be reopened.
I am experiencing this when building gcc-3.4.3 release (obtained from
ftp.gnu.org/gnu on 20.11.2004) on ix86-linux with gcc-3.4.2 (found
to be stable for building a lot of other software). Other relevant
stats
* not any distribution, but some components from Knoppix 3.6
* make-3.80
* binutils-2.15.92.0.2 (from kernel.org, built using said gcc-3.4.2)
* glibc-2.3.2
* compiling on rather slow machine (hence races more probable)
From some googling around, I got suggestion from Andreas Jaeger,
http://gcc.gnu.org/ml/gcc/2004-06/msg00203.html, that this
could be not that easy to reproduce, thus persistence in
reporting this bug was suggested.
The commands leading to this were
mkdir build-gcc
cd build-gcc
../gcc-3.4.3/configure --prefix=/apps/gcc/3.4.3 --enable-languages=c,c++,f77
make bootstrap-lean
After about 45 minutes of compilation, following messages appear
and compilation aborts:
make[2]: Entering directory `/d/src/build-gcc/gcc'
if test -f stage_last ; then \
LAST=`cat stage_last`; rm $LAST; make LANGUAGES=c gcov gcov-dump c++ f77
BOOT_CFLAGS=-g -O2 $LAST; \
else \
make LANGUAGES=c gcov gcov-dump c++ f77 BOOT_CFLAGS=-g -O2 stage1_build; \
fi
make[3]: Entering directory `/d/src/build-gcc/gcc'
make CC= stage2/xgcc -Bstage2/ -B/apps/gcc/3.4.3/i686-pc-linux-gnu/bin/
CC_FOR_BUILD= stage2/xgcc -Bstage2/ -B/apps/gcc/3.4.3/i686-pc-linux-gnu/bin/ \
STAGE_PREFIX=stage2/ \
ADAFLAGS= CFLAGS=-g -O2 LDFLAGS=
WARN_CFLAGS=\$(GCC_WARN_CFLAGS) STRICT_WARN=-pedantic -Wno-long-long
-Wold-style-definition libdir=/apps/gcc/3.4.3/lib LANGUAGES=c gcov gcov-dump
c++ f77 MAKEINFO= MAKEINFOFLAGS=--no-split MAKEOVERRIDES= OUTPUT_OPTION=-o
\$@ \
CFLAGS=-g -O2 WERROR=
make[4]: Entering directory `/d/src/build-gcc/gcc'
stage2/xgcc -Bstage2/ -B/apps/gcc/3.4.3/i686-pc-linux-gnu/bin/ -c -g -O2
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-pedantic -Wno-long-long -Wold-style-definition -DHAVE_CONFIG_H
-DGENERATOR_FILE-I. -I. -I../../gcc-3.4.3/gcc -I../../gcc-3.4.3/gcc/.
-I../../gcc-3.4.3/gcc/../include ../../gcc-3.4.3/gcc/genconstants.c -o
genconstants.o
make[4]: stage2/xgcc: Command not found
make[4]: *** [genconstants.o] Error 127
make[4]: Leaving directory `/d/src/build-gcc/gcc'
make[3]: *** [stage3_build] Error 2
make[3]: Leaving directory `/d/src/build-gcc/gcc'
make[2]: *** [quickstrap] Error 2
make[2]: Leaving directory `/d/src/build-gcc/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/d/src/build-gcc'
make: *** [bootstrap-lean] Error 2
This failure happens only about 50% of the time (thrice in five trys
so far - the other two tries were abortive after 2 hours of
compilation due to excessive disc consumption of the java libraries),
suggesting that the race condition theory is valid.
--Sampo
P.S. I have another, much more serious, bug regarding mismatching
calling conventions when compiling static functions: taking a function
pointer to them, and then calling them in another compilation unit. It
appears that the caller uses different calling convention than the
callee when -O3 is used on Solaris Sparc -mv8. This bug happens with
caller compiled with crosscompile-sparc-gcc-3.4.2 and calling
OpenSSL-0.9.7d compiled with native-sparc-gcc-3.4.2. Apparently
OpenSSL uses this function pointer programming technique a lot. Not
sure if in C its legal to take function pointers from static
functions, in which case this would be OpenSSL bug, or whether gcc
actually gets it wrong (latter is my theory, and if former is the
case, then gcc should at least emit a warning with -Wall). Compiling
without any optimization makes the problem go away. I know, I do not
have reduced test case etc. so probably you guys are not interested -
that's why I piggy backed it as a teaser to a more tractable bug
report :-) (Soap box: by making it too difficult to report bugs,
people who actually know their compiler stuff, like me, are less
likely to report the real bugs. For example, in my present case the
system is far too much hacked to reduce it to a simple test case, yet
my gut feeling (and it is this gut feeling that is the valuable
insight that can save you days of debugging time) says this is a real
bug and not due to cross compilation or some detail of my setup (apart
from OpenSSL which seems clearly indicted). Perhaps there should be
some privileged bug reporting channel for people like me? Perhaps
there already is, but I just do not know what it is?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18310
