iozone 3.218 and 3.221 get an internal compiler error in in try_split at emit-rtl.c:3326 when compiling with gcc-3.4.1; compiling with gcc-3.3.4 works perfectly. Reproducible: Always Steps to Reproduce: 1. gcc-config i686-pc-linux-gnu-3.4.1 2. source /etc/profile 3. emerge iozone Actual Results: gcc -march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer -c -o libasync.o libasync.c iozone.c: In function `do_compute': iozone.c:16294: internal compiler error: in try_split, at emit-rtl.c:3326 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugs.gentoo.org/> for instructions. Preprocessed source stored into /var/tmp/portage/iozone-3.218/temp/ccXvVxrH.out file, please attach this to your bugreport. make: *** [iozone_linux.o] Error 1 !!! ERROR: app-benchmarks/iozone-3.218 failed. !!! Function src_compile, Line 63, Exitcode 2 !!! Compile failed Expected Results: successful emerge gcc-3.4.1-r2 (non-hardened); glibc-2.3.3.20040420; linux26-headers-2.6.7-r3; CFLAGS="-march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer"
Created attachment 37053 [details] preprocessed source file, iozone-3.218 Preprocessed source stored into /var/tmp/portage/iozone-3.218/temp/ccXvVxrH.out file, please attach this to your bugreport.
Created attachment 37054 [details] preprocessed source file, iozone-3.221 Preprocessed source stored into /var/tmp/portage/iozone-3.221/temp/ccVKnU1o.out file, please attach this to your bugreport.
both emerge fine for me with gcc 3.4.1 20040803 (gentoo Linux 3.4.1-r2, ssp-3.4.2, pie-8.7.6.5)
Portage 2.0.51_pre17 (default-x86-2004.2, gcc-3.4.1, glibc-2.3.3.20040420-r1, 2.6.7-gentoo-r11 i686 Celeron (Coppermine)) ================================================================= System uname: 2.6.7-gentoo-r11 i686 Celeron (Coppermine) Gentoo Base System version 1.4.16 distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.3 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux-headers-2.4.21-r1,sys-kernel/linux-headers-2.4.19-r1 Libtools: sys-devel/libtool-1.4.3-r4 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -O2 -pipe" Works for me too.
OK, the bug only seems to trigger when I have -march=athlon-xp with gcc-3.4.1; if I set CFLAGS to "-march=i686 -O2 -pipe -frename-registers -fomit-frame-pointer", it compiles fine. Perhaps some GCC people could look at this? Why is -march=athlon-xp unsafe with gcc-3.4 ?
Still no problems: env ACCEPT_KEYWORDS=~x86 CFLAGS="-march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer" emerge iozone Calculating dependencies ...done! >>> emerge (1 of 1) app-benchmarks/iozone-3.221 to / >>> md5 src_uri ;-) iozone3_221.tar >>> Unpacking source... >>> Unpacking iozone3_221.tar to /var/tmp/portage/iozone-3.221/work >>> Source unpacked. Building iozone for Linux gcc -march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer -Dunix -c -DHAVE_ANSIC_C -DASYNC_IO -DHAVE_PREAD \ -DSHARED_MEM -Dlinux -D_LARGEFILE64_SOURCE iozone.c \ -DNAME='"linux"' -o iozone_linux.o gcc -march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer -c -o libbif.o libbif.c gcc -march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer -c -o libasync.o libasync.c gcc -march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer -Dunix -c -DHAVE_ANSIC_C -DASYNC_IO -D_LARGEFILE64_SOURCE \ -DSHARED_MEM -Dlinux libbif.c -o libbif.o gcc -march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer -Dunix -c -Dlinux -DHAVE_ANSIC_C -DASYNC_IO \ -D_LARGEFILE64_SOURCE libasync.c -o libasync.o gcc -march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer -Dunix -DHAVE_ANSIC_C -DSHARED_MEM -DASYNC_IO \ -D_LARGEFILE64_SOURCE -Dlinux \ iozone_linux.o libasync.o libbif.o -lpthread \ -lrt -o iozone >>> Test phase [not enabled]: app-benchmarks/iozone-3.221 >>> Install iozone-3.221 into /var/tmp/portage/iozone-3.221/image/ category app-benchmarks Portage 2.0.51_pre17 (default-x86-2004.2, gcc-3.4.1, glibc-2.3.3.20040420-r0, 2.6.7-gentoo-r11 i686 AMD Athlon(tm) XP 2500+) ================================================================= System uname: 2.6.7-gentoo-r11 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.4.16 distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.3 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux26-headers-2.6.7-r3 Libtools: sys-devel/libtool-1.4.3-r4 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" bash-2.05b# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 10 model name : AMD Athlon(tm) XP 2500+ stepping : 0 cpu MHz : 1837.612 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow bogomips : 3629.05 Is this a gcc-3.4.1-r2 problem or gcc-3.4.1 Still cannot repoduce this on a Athlon XP. Can you try remerging gcc-3.4.1-r1 just to be sure.
1. gcc-3.4.1-r1 is not available 2. same errors with hardened gcc-3.4.1 CFLAGS="-march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer" 3. removing or adding -frename-registers and -fomit-frame-pointer has no effects with gcc-3.4.1 4. changing to "-march=i686 -O2" has no effects in 3.4.1 (i.e. doesn't compile) 5. "-march=athlon-xp -O1" does not compile 6. "-march=athlon-xp -O0" *does* compile fine with gcc-3.4.1 7. In general, setting optimization to -O0 seems to be the only way I can avoid this with gcc-3.4.1 Anyway, I have the same CPU (athlon xp 2500), same kernel and headers, and presumably the same compiler (gcc-3.4.1 hardened), and presumably the same glibc (2.3.3.20040420 hardened). The only thing I can think of is that my glibc was compiles with hardened gcc-3.3.3, which shouldn't matter because the C ABI didn't change. I have no idea what could be causing the errror.
OK, I've isolated the problem: compiling the following with gcc-3.4.1 -mtune=i686 -O (or -mtune=athlon-xp etc, but not -mtune=i586) on my system produces an internal compiler error: ---snip iozone-test.c--- float foo(float x) { if(x == (float)0) return(0); } ---snip--- xrostov@sunnyvale tmp $ /usr/libexec/gcc/i686-pc-linux-gnu/3.4.1/cc1 foo.c -mtune=i686 -O -o - .file "foo.c" foo foo.c: In function `foo': foo.c:6: internal compiler error: in try_split, at emit-rtl.c:3326 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugs.gentoo.org/> for instructions. Dragonheart, do you have any problems compiling foo.c with any compiler switches? A couple of comments. First, the function is not in good C style - there is no default return value. Adding return(0) at the end of the function removes the compiler errror (note that do_compute() in iozone does not have a return at the end of the function). Second, the gcc manual says that "-O" means "-fdefer-pop -fmerge-constants -fthread-jumps -floop-optimize -fif-conversion -fif-conversion2 -fdelayed-branch -fguess-branch-probability -fcprop-registers -fomit-frame-pointer". I tried to compile with those switches, and there were no errors. So it seems that -O combined with -mtune=i686 turns on something hidden in my version of gcc-3.4.1
Sorry, typo, that should have been ---snip foo.c---
very good analysis. Hardened peoples - what are your thoughts? I'm compiling gcc-3.4.1-r1(hardened) now.
compiles fine here with gcc-3.4.1-r2, binutils-2.14.90.0.8 20040114, glibc-2.3.4.20040619-r1
iozone-3.221-r1.ebuild commited with a patch to put return values on functions. Note also that 0 is an int and 0.0 is a float in your code. Maybe an inplicit conversion problem in your version of gcc for some reason. Reopen if there are problems. Passing onto a few arch testers too. FYI includes src_test routine.
arm added to 3.221-r1
I just tried to build app-benchmark/iozone-3.226 on ppc64, but I get this: make: *** No rule to make target `linux-ppc64'. Stop So we need a ppc64 rule. Anybody volunteer for writing one? 0:-) Markus
this has been easier than I thought. I've added app-bechmark/iozone-3.226-r1 which includes the ppc64 patch and have added ~ppc64 to KEYWORDS. Markus
updating version in title. Good one Markus. Includes src_test routine for testing.
