| Summary: | 3.226-r1 arch test | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alexandre Rostovtsev (RETIRED) <tetromino> |
| Component: | [OLD] Unspecified | Assignee: | Daniel Black (RETIRED) <dragonheart> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | normal | CC: | alpha, f5d8fd51ed1e804c9e8d0357e8614e0493b06e96, hardened, ia64, osx |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
preprocessed source file, iozone-3.218
preprocessed source file, iozone-3.221 |
||
|
Description
Alexandre Rostovtsev (RETIRED)
2004-08-08 11:53:20 UTC
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. |