Red Hat Bugzilla – Bug 240772
gcc-3.2.3 i386 can not bootstrap gcc-4.2.0, gcc-3.4.6 can
Last modified: 2007-11-16 20:14:46 EST
Description of problem: On i386, using gcc-3.2.3-58.i386 bootstraping gcc-4.2.0 released version fails but using gcc-3.4.6 works. On x86_64 gcc-3.2.3-58.x86_64 bootstraps fine (glibc-devel.i386 and x86_64 installed). Version-Release number of selected component (if applicable): 3.2.3-58.i386 How reproducible: always Steps to Reproduce: 1. tar xzf gcc-4.2.0.tar.gz 2. mkdir build && cd build && ../gcc-4.2.0/configure && make 3. Actual results: Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs Bootstrap comparison failure! ./cfg.o differs ./cfgloopanal.o differs ./loop-iv.o differs ./predict.o differs ./profile.o differs ./value-prof.o differs ./ipa-inline.o differs make[2]: *** [compare] Error 1 make[1]: *** [stage3-bubble] Error 2 make: *** [all] Error 2 Expected results: no errors Additional info: bootstrapping with a home built gcc-3.4.6 yields no error. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382 mention the same bug but was closed because no feedback was given by the reporter
Some places in i386.c are miscompiled by gcc 3.2.x with -O0 -fkeep-inline-functions, e.g. typedef struct rtx_def *rtx; enum machine_mode { VOIDmode = 0, DImode = 13 }; extern rtx gen_rtx_CONST_INT (enum machine_mode, long); extern rtx gen_x86_shld_1 (rtx, rtx, rtx); static __inline__ rtx gen_x86_64_shld(rtx a, rtx b, rtx c) { return 0; } extern rtx emit_insn (rtx); void foo (rtx *high, rtx *low, enum machine_mode mode, int count) { emit_insn ((mode == DImode ? gen_x86_shld_1 : gen_x86_64_shld) (high[0], low[0], gen_rtx_CONST_INT (VOIDmode, count))); } will unconditionally call gen_x86_64_shld, no matter what mode contains. Removing -fkeep-inline-functions or compiling with optimizations cures this. Will investigate more, that said, this was reported too late to be fixed in RHEL3.9's gcc and it might be a good idea to workaround this in gcc 4.2+ anyway.
Further details in the upstream PR. This will be worked around in GCC 4.2.1/4.3+, it is too late to fix this in RHEL3.9 and the bug isn't severe enough to warrant an asynchronous gcc errata, so closing as WONTFIX. http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/calls.c.diff?cvsroot=gcc&r1=1.287&r2=1.288 ought to fix the problem.