[Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c

["winfried dot magerl at t-online dot de" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866

--- Comment #3 from Winfried Magerl <winfried.magerl@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.