------- 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