http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
--- Comment #3 from Winfried Magerl <winfried.mag...@t-online.de> 2013-04-11 18:46:44 UTC --- Hi Uros, On Mon, Apr 08, 2013 at 09:26:51PM +0000, ubizjak at gmail dot com wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866 > > --- Comment #2 from Uros Bizjak <ubizjak at gmail dot com> 2013-04-08 > 21:26:51 UTC --- > > Created attachment 29820 [details] > > tar-file with small set of c-files to reproduce the problem > > I can't recreate the problem with your script (to compile successfully, I > removed -static from the command). All binaries were executed without > problems > on corei7, with provided -march and -O2 flags. The binaries were linked with > glibc-2.16, though. the short setup depends on an installed 2.17 for compatibility and the '-static' is necessary to see the problem because it looks like without '-static' the linked libm doesn't use the functions from 'sha512.a' (don't know exactly why). You can always use the trivial way which should work with every linux-system: compile glibc-2.17 with 'export CC="gcc -march=bdver2"' and run test-suite. I've done some further checks to see which feature show the fault because I know that '-march=amdfam10' doesn't show the problem. and it turns out that '-mxop' shows the error (XOP was introduced with support for bdver1/bdver2). '-O3 -march=bdver2 -mno-xop' -> OKAY '-O3 -march=amdfam10 -mxop' -> FAIL All Tests verified on OpenSuSE-11.3 ith gcc-4.7.2 to prevent discussion about self-compiled libs/gcc/system. As far as I've read the documentation/source XOP is pure AMD-Feature and not supported on corei7. Would be great if you can find another gcc-developer with apropriate CPU to confirm the problem (maybe some of the developers from @amd.com). > Please follow the instructions at [1] to provide a *minimized* runtime > testcase > that exposes the failure, without dependencies on system libc. it's already "*minimized* runtime testcase" I can provide and do not have the necesary skills to go further. > BTW: From your report it is not clear if the problem is indeed in the > compiler, > or in the system glibc. Because I can not guarantee that this bug is pure gcc bug. But from test-suites (gcc-testsuite/glibc-testsuite) it looks like support of bdver1/2 in gcc is not working well. The different test-fails on glibc when enabling bdver1 or bdver2 (sha512-errors only with -O3): make[2]: *** [/home/winfried/glibc-cvs/glibc-2.17-xop-none/math/test-float.out] Error 1 make[2]: *** [/home/winfried/glibc-cvs/glibc-2.17-xop-none/math/test-double.out] Error 1 make[2]: *** [/home/winfried/glibc-cvs/glibc-2.17-xop-none/math/test-ifloat.out] Error 1 make[2]: *** [/home/winfried/glibc-cvs/glibc-2.17-xop-none/math/test-idouble.out] Error 1 make[2]: *** [/home/winfried/glibc-cvs/glibc-2.17-xop-none/crypt/sha512c-test.out] Error 1 make[2]: *** [/home/winfried/glibc-cvs/glibc-2.17-xop-none/crypt/sha512test.out] Error 1 Additional erors when compiling recent gcc-4.8.x with '--with-arch=bdver2' (excluding additional 203 FAILS for scan-asembler and friends): +FAIL: gcc.c-torture/execute/pr51581-1.c execution, -O3 -fomit-frame-pointer +FAIL: gcc.c-torture/execute/pr51581-1.c execution, -O3 -fomit-frame-pointer -funroll-loops +FAIL: gcc.c-torture/execute/pr51581-1.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions +FAIL: gcc.c-torture/execute/pr51581-1.c execution, -O3 -g +FAIL: gcc.c-torture/execute/pr51581-2.c execution, -O3 -fomit-frame-pointer +FAIL: gcc.c-torture/execute/pr51581-2.c execution, -O3 -fomit-frame-pointer -funroll-loops +FAIL: gcc.c-torture/execute/pr51581-2.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions +FAIL: gcc.c-torture/execute/pr51581-2.c execution, -O3 -g +FAIL: gcc.c-torture/execute/pr53645.c execution, -O1 +FAIL: gcc.c-torture/execute/pr53645.c execution, -O2 +FAIL: gcc.c-torture/execute/pr53645.c execution, -O3 -fomit-frame-pointer +FAIL: gcc.c-torture/execute/pr53645.c execution, -O3 -fomit-frame-pointer -funroll-loops +FAIL: gcc.c-torture/execute/pr53645.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions +FAIL: gcc.c-torture/execute/pr53645.c execution, -O3 -g +FAIL: gcc.c-torture/execute/pr53645.c execution, -Os +FAIL: gcc.c-torture/execute/pr53645.c execution, -Og -g +FAIL: gcc.c-torture/execute/pr53645.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none +FAIL: gcc.c-torture/execute/pr53645.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects +FAIL: gcc.dg/vect/pr51581-1.c execution test +FAIL: gcc.dg/vect/pr51581-2.c execution test +FAIL: gcc.dg/vect/pr51581-3.c execution test +FAIL: gcc.dg/vect/pr51581-1.c -flto execution test +FAIL: gcc.dg/vect/pr51581-2.c -flto execution test +FAIL: gcc.dg/vect/pr51581-3.c -flto execution test +FAIL: gcc.target/i386/avx-mul-1.c execution test +FAIL: gcc.target/i386/avx-pr51581-1.c execution test +FAIL: gcc.target/i386/avx-pr51581-2.c execution test +FAIL: gcc.target/i386/sse2-mul-1.c execution test +FAIL: gcc.target/i386/sse4_1-mul-1.c execution test SInce this errors only show up with bdver1/2 I think the probability that gcc has the bug is very high. And because in this specific case I can reproduce the problem with -mxop it might be a bug in the xop-implementation. Also glibc doesn't check for XOP and in the minimal set I've provided (I know, only usable with glibc-2.17 installed, static libs available and with CPU bdver1/2) I didn't see any asembler-code. regards winfried > [1] http://gcc.gnu.org/bugs/ > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug.
