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

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

[winfried.magerl@t-online.de]

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

             Bug #: 56866
           Summary: gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2'
                    misscompiles glibc-2.17/crypt/sha512.c
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: winfried.magerl@t-online.de


compiling glibc-2.17 with 'O3 -march=bdver2' fails crypt-test when running
'make check' after glibc-build. I've already tested with different
compilers/settings and the problem exists with gcc-4.7.x and gcc-4.8.x when
using '-O3 -march=bdver1' or '-O3 -march=bdver2' (-O2 is fine) and the affected
file is glibc-2.17/crypt/sha512.c.

I've attached a tar-file which includes necessary files from glibc-2.17
(sha512-block.c/sha512.c/sha512.h) and a modified version of sha512c-test.c
(removed dependency to glibc-test-environment). Might not work if system-libc
is not 2.17
(recompiling glibc and run test-suite should always work.
A small test-script test-gcc.sh to demonstrate the problem. Verified on:

gcc (GCC) 4.8.1 20130407 / glibc-2.17
gcc (GCC) 4.7.2 20130108 / opensuse-12.3 / glibc-2.17

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

[winfried.magerl@t-online.de]

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

--- Comment #1 from Winfried Magerl <winfried.magerl@t-online.de> 2013-04-07 16:55:00 UTC ---
Created attachment 29820
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29820
tar-file with small set of c-files to reproduce the problem

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-04-09
     Ever Confirmed|0                           |1

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

[winfried.magerl@t-online.de]

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.

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

[ubizjak at gmail dot com]

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

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED
                 CC|                            |venkataramanan.kumar at amd
                   |                            |dot com
     Ever Confirmed|1                           |0

--- Comment #4 from Uros Bizjak <ubizjak at gmail dot com> 2013-04-11 19:35:59 UTC ---
Adding a CC to confirm the problem, at least in gcc.target/i386, with bdver2.

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

[winfried.magerl@t-online.de]

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

--- Comment #5 from Winfried Magerl <winfried.magerl@t-online.de> 2013-04-11 21:07:43 UTC ---
Hi,

On Thu, Apr 11, 2013 at 08:46:34PM +0200, Winfried Magerl wrote:
> > 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

I've disabled XOP in the current gcc-4.8-branch with the following diff:

--- gcc-4.8-branch/gcc/config/i386/i386.c       2013-04-03 08:09:26.409746225
+0200
+++ gcc-4.8-noxop/gcc/config/i386/i386.c        2013-04-11 20:55:21.671710214
+0200
@@ -2972,12 +2972,12 @@
        PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
        | PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1
        | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX | PTA_FMA4
-       | PTA_XOP | PTA_LWP | PTA_PRFCHW | PTA_FXSR | PTA_XSAVE},
+       | PTA_LWP | PTA_PRFCHW | PTA_FXSR | PTA_XSAVE},
       {"bdver2", PROCESSOR_BDVER2, CPU_BDVER2,
        PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
        | PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1
        | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX | PTA_FMA4
-       | PTA_XOP | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C
+       | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C
        | PTA_FMA | PTA_PRFCHW | PTA_FXSR | PTA_XSAVE},
       {"bdver3", PROCESSOR_BDVER3, CPU_BDVER3,
        PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3

After all the tests I've already done the result is not
realy surprising:

gcc-4.8 configured with '--with-arch=bdver2':
    all additional execution-errors listed above do no
    longer FAIL (still more then 200 scan-*-errors which
    might be a bug in the tests)

glibc-2.17 compiled with '-O3' and the above compiler using
'-march=bdver2' as default-optimisation:
    both sha512-errors are gone (still the scary double/float-errors
    but this tests are obviously not related to XOP)

test-cases are enough in the gcc-source-tree as shown above and this
test-cases most likely fullfill all requirements for the bug-list
better then my extracted files from glibc.

There's still a small chance that I'm a lucky owner of a AMD-CPU which
has only problems with XOP-instructionset. Would be great if someone
confirm this.

Detailed CPU-Information from /proc/cpuinfo:
    cpu family      : 21
    model           : 2
    model name      : AMD FX(tm)-6300 Six-Core Processor
    stepping        : 0
    microcode       : 0x600081c

and from dmesg:
    CPU0: AMD FX(tm)-6300 Six-Core Processor (fam: 15, model: 02, stepping: 00)

regards

    winfried

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

[mikpe at it dot uu.se]

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

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu.se

--- Comment #6 from Mikael Pettersson <mikpe at it dot uu.se> 2013-04-12 12:42:26 UTC ---
I've bootstrapped and regtested gcc-4.7.3 on an Opteron 6278, with and without
--with-arch=bdver1.  With --with-arch=bdver1 there were numerous regressions in
gcc.dg/vect/ and gcc.target/i386/{,l-}fma*, and one in
gcc.target/i386/pr42542-4a.c.  I don't know if these indicate wrong-code or
missed-optimization.

I'd be willing to run specific wrong-code test cases on this machine, if
they're completely standalone (not depending on recent glibc).

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

[winfried.magerl@t-online.de]

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

--- Comment #7 from Winfried Magerl <winfried.magerl@t-online.de> 2013-04-12 18:42:48 UTC ---
Hi,

On Fri, Apr 12, 2013 at 12:42:26PM +0000, mikpe at it dot uu.se wrote:
> --- Comment #6 from Mikael Pettersson <mikpe at it dot uu.se> 2013-04-12 12:42:26 UTC --- 
> I've bootstrapped and regtested gcc-4.7.3 on an Opteron 6278, with and without 
> --with-arch=bdver1.  With --with-arch=bdver1 there were numerous regressions in 
> gcc.dg/vect/ and gcc.target/i386/{,l-}fma*, and one in 
> gcc.target/i386/pr42542-4a.c.  I don't know if these indicate wrong-code or 
> missed-optimization. 

something like egrep '^FAIL.+execution' to get the scary
errors (currently I think all that scan-*-errors are simply
false positive).

> I'd be willing to run specific wrong-code test cases on this machine, if 
> they're completely standalone (not depending on recent glibc). 

Don't know how to pick out single gcc-testcases from the
testsuite for standalone-testing.

In any case it's possible th check the whole package. gcc/glibc have a big
test-suite and it's not necessary to install them to run the test-suite.
And I have already provided the differences I see when enabling 'bdver2'
compared with 'amdfam10'

for gcc something like this (out of the head with typos included):

--------------------------------------------
cd /to/your/favorite/builddir
wget ftp:///ftp.gnu.org/gnu/gcc/gcc-4.8.0/gcc-4.8.0.tar.bz2
tar -xf gcc-4.8.0.tar.bz2
mkdir build
mkdir build-bdver1
cd build/
../gcc-4.8.0/configure --enable-multilib=no --enable-languages='c,c++'
make -j8 >& make.out
make -j8 -k check >& check.out
../gcc-4.8/contrib/test_summary >& test_summary.out
cd ../build-bdver1
../gcc-4.8.0/configure --enable-multilib=no --enable-languages='c,c++'
--with-arch=bdver1
make -j8 >& make.out
make -j8 -k check >& check.out
../gcc-4.8/contrib/test_summary >& test_summary.out
cd ..
diff -u build/test_summary.out build-bdver1/test_summary.out | egrep
'^\+.+execution'
----------------------------------------------

some notes:
    --enable-multilib=no        -> only x86_64
    --enable-languages='c,c++'    -> only c-tests are of interest
    make -j8            -> depends on your CPU
    egrep '^\+.+execution'        -> for easier comparison with the diff I've
provided
    --with-arch=bdver1        -> your CPU is bdver1

for glibc it's something similar:

--------------------------------------------
cd /to/your/favorite/builddir
wget ftp:///ftp.gnu.org/glibc/glibc-2.17.tar.xz
tar -xf glibc-2.17.tar.xz
mkdir build
mkdir build-bdver1
cd build/
export CC='gcc'
export CFLAGS='-O3'
../glibc-2.17/configure
make -j8 >& make.out
make -k -j8 check >& check.out
cd ../build-bdver1
export CC='gcc -march=bdver1'
../glibc-2.17/configure
make -j8 >& make.out
make -k -j8 check >& check.out
cd ..
fgrep '***' build/check.out build-bdver1/check.out
--------------------------------------------

To ensure it's XOP in glibc you can use CC='gcc -mxop' instead
of CC='gcc -march=bdver1'.

regards

    winfried

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

[mikpe at it dot uu.se]

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

--- Comment #8 from Mikael Pettersson <mikpe at it dot uu.se> 2013-04-14 15:55:32 UTC ---
OK, I can confirm that compiling glibc-2.17 with gcc-4.7.3 -O3 -march=bdver1
causes the sha512 test to fail, but without "-march=bdver1" it doesn't fail.

I also saw regressions in math/test-float.out, math/test-double.out,
math/test-ifloat.out, math/test-idouble.out, nptl/tst-cond25.out, and
rt/tst-cpuclock2.out.

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

[winfried.magerl@t-online.de]

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

--- Comment #9 from Winfried Magerl <winfried.magerl@t-online.de> 2013-04-17 18:41:06 UTC ---
Hi,

at least one confirmation. I've done some further checks about
float-errors in glibc and that FAM/FAM4 are the extension responsible
for the additional float-errors.

How to proceed?

>From my point of view and comapred with '-march=amdfam10' the
extensions XOP/FAM4/FAM are responsible for the failed tests.

Disabling it in gcc-4.8-noxop/gcc/config/i386/i386.c brings me back
to the same test-results I'm seeing with amdfam10 (excluding all
sorts of scan-*-errors).

I would propose the following patch for bdver2-support because
features which are untested and known to break code (like for example
all the additional test-errors in the gcc-testsuite) should be
disabeled:

--- gcc-4.8-noxop/gcc/config/i386/i386.c.orig   2013-04-12 20:49:09.181351855
+0200
+++ gcc-4.8-noxop/gcc/config/i386/i386.c        2013-04-12 23:15:09.112185980
+0200
@@ -2976,9 +2976,9 @@
       {"bdver2", PROCESSOR_BDVER2, CPU_BDVER2,
        PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
        | PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1
-       | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX | PTA_FMA4
-       | PTA_XOP | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C
-       | PTA_FMA | PTA_PRFCHW | PTA_FXSR | PTA_XSAVE},
+       | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX
+       | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C
+       | PTA_PRFCHW | PTA_FXSR | PTA_XSAVE},
       {"bdver3", PROCESSOR_BDVER3, CPU_BDVER3,
        PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
        | PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1

just an examp,e because the features should be disabled in bdver1/3 too
(XOP/FMA4/FMA are only available in bdver1/2/3). Maybe adding the
gcc-developers from @amd.com?

regards

    winfried

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

[mikpe at it dot uu.se]

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

--- Comment #10 from Mikael Pettersson <mikpe at it dot uu.se> 2013-04-17 20:15:47 UTC ---
(In reply to comment #9)
> How to proceed?

Derive a stand-alone test case from the failing glibc module and whatever glibc
code it requires, then minimize it.

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

[winfried.magerl@t-online.de]

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

--- Comment #11 from Winfried Magerl <winfried.magerl@t-online.de> 2013-04-17 21:02:38 UTC ---
Hi Mike,

On Wed, Apr 17, 2013 at 08:15:47PM +0000, mikpe at it dot uu.se wrote:
>  
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866 
>  
> --- Comment #10 from Mikael Pettersson <mikpe at it dot uu.se> 2013-04-17 20:15:47 UTC --- 
> (In reply to comment #9) 
> > How to proceed? 
>  
> Derive a stand-alone test case from the failing glibc module and whatever glibc 
> code it requires, then minimize it. 

If fixing broken gcc's XOP/FMA/FMA4-extensions on AMD-CPUs depends on my
ability to extract a stand-alone-test from glibc-testsuite then I'm
realy sorry for not having the necessary skills (as already stated).

Why not simply using the failing test-cases from gcc-testsuite
which are all standalone and depends on XOP:

+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

Or is this a formal problem because the subject does not realy match
the whole problem which looks like a more general problem with
extensions specific to bdver1/2/3 (and for this not reproducable
on other cpu's).

regards

    winfried

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

[glisse at gcc dot gnu.org]

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

--- Comment #12 from Marc Glisse <glisse at gcc dot gnu.org> 2013-04-17 21:49:15 UTC ---
(In reply to comment #11)
> If fixing broken gcc's XOP/FMA/FMA4-extensions on AMD-CPUs depends on my
> ability to extract a stand-alone-test from glibc-testsuite then I'm
> realy sorry for not having the necessary skills (as already stated).

Skills can be learned, and the best way is through practice. Ideally someone
with the right combination of knowledge, hardware and free time would look at
it, and you seem to be the closest currently ;-)

> Why not simply using the failing test-cases from gcc-testsuite
> which are all standalone and depends on XOP:

Good idea. I suggest you pick a simple one:

> +FAIL: gcc.target/i386/sse2-mul-1.c execution test

it looks like a list of several tests in a row. If you can first replace the
aborts with printf to determine the first one that fails, then remove
everything after that point, you have already narrowed the issue quite a bit.
Then you can try to simplify what remains. Ideally, you would get a program
small enough that posting the dumps would show the obvious issue. Do make sure
while reducing the program that it still works correctly without the bdver2
option.

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

[winfried.magerl@t-online.de]

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

--- Comment #13 from Winfried Magerl <winfried.magerl@t-online.de> 2013-04-24 20:58:13 UTC ---
Hi,

On Wed, Apr 17, 2013 at 09:49:15PM +0000, glisse at gcc dot gnu.org wrote:
>  
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866 
>  
> --- Comment #12 from Marc Glisse <glisse at gcc dot gnu.org> 2013-04-17 21:49:15 UTC --- 
> (In reply to comment #11) 
> > If fixing broken gcc's XOP/FMA/FMA4-extensions on AMD-CPUs depends on my 
> > ability to extract a stand-alone-test from glibc-testsuite then I'm 
> > realy sorry for not having the necessary skills (as already stated). 
>  
> Skills can be learned, and the best way is through practice. Ideally someone 
> with the right combination of knowledge, hardware and free time would look at 
> it, and you seem to be the closest currently ;-)

Please ask me again in 17 years when I'm hopefully finished
with regular work. Easter-Holidays might give you the wrong
for my available spare time.......

> > Why not simply using the failing test-cases from gcc-testsuite 
> > which are all standalone and depends on XOP: 
>  
> Good idea. I suggest you pick a simple one: 
>  
> > +FAIL: gcc.target/i386/sse2-mul-1.c execution test 
>  
> it looks like a list of several tests in a row. If you can first replace the 
> aborts with printf to determine the first one that fails, then remove 
> everything after that point, you have already narrowed the issue quite a bit. 
> Then you can try to simplify what remains. Ideally, you would get a program 
> small enough that posting the dumps would show the obvious issue. Do make sure 
> while reducing the program that it still works correctly without the bdver2 
> option. 

I've done some basic checks and according to gdb the first abort()
triggers with unmodified code. Replacing abort() with printf() does no
longer trigger the if-clause and the next abort() was called.

I've add a small tar-file with a simple shell-scipt check.sh which
builds two binaries with no-xop and xop as options. Tested with
self-build "gcc (GCC) 4.8.1 20130421" and stock OpenSuSE-12.3-compiler
"gcc (GCC) 4.7.2 20130108".

Searching for xop in bugzilla shows that there are bugs refering
to xop/sse2-mul-1.c/bdver2 but it looks like there's no real
progress in this area.

If you're waiting on me to become a c-developer we might have to
live with broken xop/fam/fam4-extension for the next 17 years.

For my self-build home-linux which is mostly a hobby I can live
with this simple patch:

--- gcc-4.8-noxop/gcc/config/i386/i386.c.orig   2013-04-12 20:49:09.181351855
+0200
+++ gcc-4.8-noxop/gcc/config/i386/i386.c        2013-04-12 23:15:09.112185980
+0200
@@ -2976,9 +2976,9 @@
       {"bdver2", PROCESSOR_BDVER2, CPU_BDVER2,
        PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
        | PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1
-       | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX | PTA_FMA4
-       | PTA_XOP | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C
-       | PTA_FMA | PTA_PRFCHW | PTA_FXSR | PTA_XSAVE},
+       | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX
+       | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C
+       | PTA_PRFCHW | PTA_FXSR | PTA_XSAVE},
       {"bdver3", PROCESSOR_BDVER3, CPU_BDVER3,
        PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
        | PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1

I'm still wondering why the extensions where enabled when the test-suite
shows 179 additinal FAIL in 36 different c-files (current gcc-4.8.branch).

If I can help testing feel free to send me an e-mail.

regards

    winfried

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

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-26 09:00:42 UTC ---
Created attachment 29944
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29944
gcc49-pr56866.patch

The fix for gcc.c-torture/execute/pr51581* and pr53645.c etc. is quite obvious,
we obviously can't use xop_pmacsdqh with unsigned highpart odd multiplication,
say for the pr51581-1.c unsigned division by 3U, which is high part
multiplication by 0xaaaaaaabU, with the result shifted right by 1 at the end.
If we compute say 3ULL * 0xaaaaaaabULL, we can't use xop_pmacsdqh which
computes
3LL * 0xffffffffaaaaaaabLL instead.

That said, there are no vpmacsdqh insns in the sha512 code for -O3
-march=bdver2, so it must be something else.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #29944|0                           |1
        is obsolete|                            |
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|2013-04-09 00:00:00         |2013-04-26
         AssignedTo|unassigned at gcc dot       |jakub at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-26 12:04:12 UTC ---
Created attachment 29947
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29947
gcc49-pr56866.patch

Updated (untested) patch that should fix also the sha512 miscompilation.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-27 12:30:55 UTC ---
Author: jakub
Date: Sat Apr 27 12:26:05 2013
New Revision: 198355

URL: http://gcc.gnu.org/viewcvs?rev=198355&root=gcc&view=rev
Log:
    PR target/56866
    * config/i386/i386.c (ix86_expand_mul_widen_evenodd): Don't
    use xop_pmacsdqh if uns_p.
    * config/i386/sse.md (xop_rotr<mode>3): Fix up computation of
    the immediate rotate count.

    * gcc.c-torture/execute/pr56866.c: New test.
    * gcc.target/i386/pr56866.c: New test.

Added:
    trunk/gcc/testsuite/gcc.c-torture/execute/pr56866.c
    trunk/gcc/testsuite/gcc.target/i386/pr56866.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/config/i386/sse.md
    trunk/gcc/testsuite/ChangeLog

Author: jakub
Date: Sat Apr 27 12:27:08 2013
New Revision: 198356

URL: http://gcc.gnu.org/viewcvs?rev=198356&root=gcc&view=rev
Log:
    PR target/56866
    * config/i386/i386.c (ix86_expand_mul_widen_evenodd): Don't
    use xop_pmacsdqh if uns_p.
    * config/i386/sse.md (xop_rotr<mode>3): Fix up computation of
    the immediate rotate count.

    * gcc.c-torture/execute/pr56866.c: New test.
    * gcc.target/i386/pr56866.c: New test.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr56866.c
    branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr56866.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/i386/i386.c
    branches/gcc-4_8-branch/gcc/config/i386/sse.md
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

Author: jakub
Date: Sat Apr 27 12:28:45 2013
New Revision: 198357

URL: http://gcc.gnu.org/viewcvs?rev=198357&root=gcc&view=rev
Log:
    PR target/56866
    * config/i386/sse.md (xop_rotr<mode>3): Fix up computation of
    the immediate rotate count.

    * gcc.c-torture/execute/pr56866.c: New test.
    * gcc.target/i386/pr56866.c: New test.

Added:
    branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/execute/pr56866.c
    branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr56866.c
Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/config/i386/sse.md
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.7.4
            Summary|gcc 4.7.x/gcc-4.8.x with    |[4.7/4.8/4.9 Regression]
                   |'-O3 -march=bdver2'         |with '-O3 -march=bdver2'
                   |misscompiles                |misscompiles
                   |glibc-2.17/crypt/sha512.c   |glibc-2.17/crypt/sha512.c

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

[winfried.magerl@t-online.de]

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

--- Comment #17 from Winfried Magerl <winfried.magerl@t-online.de> 2013-04-29 16:08:09 UTC ---
Hi Jakub,

On Fri, Apr 26, 2013 at 09:00:42AM +0000, jakub at gcc dot gnu.org wrote:
>  
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866 
>  
> --- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-26 09:00:42 UTC --- 
> Created attachment 29944 
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29944 
> gcc49-pr56866.patch 
>  
> The fix for gcc.c-torture/execute/pr51581* and pr53645.c etc. is quite obvious, 
> we obviously can't use xop_pmacsdqh with unsigned highpart odd multiplication, 
> say for the pr51581-1.c unsigned division by 3U, which is high part 
> multiplication by 0xaaaaaaabU, with the result shifted right by 1 at the end. 
> If we compute say 3ULL * 0xaaaaaaabULL, we can't use xop_pmacsdqh which 
> computes 
> 3LL * 0xffffffffaaaaaaabLL instead. 
>  
> That said, there are no vpmacsdqh insns in the sha512 code for -O3 
> -march=bdver2, so it must be something else. 

I've verified that the problem with the sha512 code build with
'-O3 -mxop' is also fixed. I've attached sha512.s.diff with the
diff of the generated assembler-code (gcc-4_8-branch revision 198317
compared with gcc-4_8-branch revision 198422).

Most lines looks like this:

-       vprotq  $-45, %xmm0, %xmm4
-       vprotq  $-3, %xmm0, %xmm3
+       vprotq  $3, %xmm0, %xmm4
+       vprotq  $45, %xmm0, %xmm3

Many thanks for looking at this issue! I will run the complete
gcc-test-suite to see the difference and later on I will check
glibc-testsuite too.

It might be a good idea to look at the other open bugs tagged
with bdver or xop.

regards

    winfried