Bug 240772

Summary: gcc-3.2.3 i386 can not bootstrap gcc-4.2.0, gcc-3.4.6 can
Product: Red Hat Enterprise Linux 3 Reporter: Tru Huynh <pasteur>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.8   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-05-30 12:21:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tru Huynh 2007-05-21 15:57:01 UTC 
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
Comment 1 Jakub Jelinek 2007-05-29 09:57:48 UTC 
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.
Comment 2 Jakub Jelinek 2007-05-30 12:21:25 UTC 
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.