* [Bug c/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
@ 2013-04-07 16:55 ` winfried.magerl@t-online.de
2013-04-09 13:47 ` [Bug target/56866] " rguenth at gcc dot gnu.org
` (16 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: winfried.magerl@t-online.de @ 2013-04-07 16:55 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
2013-04-07 16:55 ` [Bug c/56866] " winfried.magerl@t-online.de
@ 2013-04-09 13:47 ` rguenth at gcc dot gnu.org
2013-04-11 18:46 ` winfried.magerl@t-online.de
` (15 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-04-09 13:47 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
2013-04-07 16:55 ` [Bug c/56866] " winfried.magerl@t-online.de
2013-04-09 13:47 ` [Bug target/56866] " rguenth at gcc dot gnu.org
@ 2013-04-11 18:46 ` winfried.magerl@t-online.de
2013-04-11 19:36 ` ubizjak at gmail dot com
` (14 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: winfried.magerl@t-online.de @ 2013-04-11 18:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (2 preceding siblings ...)
2013-04-11 18:46 ` winfried.magerl@t-online.de
@ 2013-04-11 19:36 ` ubizjak at gmail dot com
2013-04-11 21:07 ` winfried.magerl@t-online.de
` (13 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: ubizjak at gmail dot com @ 2013-04-11 19:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (3 preceding siblings ...)
2013-04-11 19:36 ` ubizjak at gmail dot com
@ 2013-04-11 21:07 ` winfried.magerl@t-online.de
2013-04-12 12:42 ` mikpe at it dot uu.se
` (12 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: winfried.magerl@t-online.de @ 2013-04-11 21:07 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (4 preceding siblings ...)
2013-04-11 21:07 ` winfried.magerl@t-online.de
@ 2013-04-12 12:42 ` mikpe at it dot uu.se
2013-04-12 18:42 ` winfried.magerl@t-online.de
` (11 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: mikpe at it dot uu.se @ 2013-04-12 12:42 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (5 preceding siblings ...)
2013-04-12 12:42 ` mikpe at it dot uu.se
@ 2013-04-12 18:42 ` winfried.magerl@t-online.de
2013-04-14 15:55 ` mikpe at it dot uu.se
` (10 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: winfried.magerl@t-online.de @ 2013-04-12 18:42 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (6 preceding siblings ...)
2013-04-12 18:42 ` winfried.magerl@t-online.de
@ 2013-04-14 15:55 ` mikpe at it dot uu.se
2013-04-17 18:41 ` winfried.magerl@t-online.de
` (9 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: mikpe at it dot uu.se @ 2013-04-14 15:55 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (7 preceding siblings ...)
2013-04-14 15:55 ` mikpe at it dot uu.se
@ 2013-04-17 18:41 ` winfried.magerl@t-online.de
2013-04-17 20:15 ` mikpe at it dot uu.se
` (8 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: winfried.magerl@t-online.de @ 2013-04-17 18:41 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (8 preceding siblings ...)
2013-04-17 18:41 ` winfried.magerl@t-online.de
@ 2013-04-17 20:15 ` mikpe at it dot uu.se
2013-04-17 21:02 ` winfried.magerl@t-online.de
` (7 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: mikpe at it dot uu.se @ 2013-04-17 20:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (9 preceding siblings ...)
2013-04-17 20:15 ` mikpe at it dot uu.se
@ 2013-04-17 21:02 ` winfried.magerl@t-online.de
2013-04-17 21:49 ` glisse at gcc dot gnu.org
` (6 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: winfried.magerl@t-online.de @ 2013-04-17 21:02 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (10 preceding siblings ...)
2013-04-17 21:02 ` winfried.magerl@t-online.de
@ 2013-04-17 21:49 ` glisse at gcc dot gnu.org
2013-04-24 20:58 ` winfried.magerl@t-online.de
` (5 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: glisse at gcc dot gnu.org @ 2013-04-17 21:49 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (11 preceding siblings ...)
2013-04-17 21:49 ` glisse at gcc dot gnu.org
@ 2013-04-24 20:58 ` winfried.magerl@t-online.de
2013-04-26 9:00 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: winfried.magerl@t-online.de @ 2013-04-24 20:58 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (12 preceding siblings ...)
2013-04-24 20:58 ` winfried.magerl@t-online.de
@ 2013-04-26 9:00 ` jakub at gcc dot gnu.org
2013-04-26 12:04 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-04-26 9:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (13 preceding siblings ...)
2013-04-26 9:00 ` jakub at gcc dot gnu.org
@ 2013-04-26 12:04 ` jakub at gcc dot gnu.org
2013-04-27 12:31 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-04-26 12:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (14 preceding siblings ...)
2013-04-26 12:04 ` jakub at gcc dot gnu.org
@ 2013-04-27 12:31 ` jakub at gcc dot gnu.org
2013-04-27 12:32 ` [Bug target/56866] [4.7/4.8/4.9 Regression] " jakub at gcc dot gnu.org
2013-04-29 16:08 ` winfried.magerl@t-online.de
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-04-27 12:31 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] [4.7/4.8/4.9 Regression] with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (15 preceding siblings ...)
2013-04-27 12:31 ` jakub at gcc dot gnu.org
@ 2013-04-27 12:32 ` jakub at gcc dot gnu.org
2013-04-29 16:08 ` winfried.magerl@t-online.de
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-04-27 12:32 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/56866] [4.7/4.8/4.9 Regression] with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
2013-04-07 16:53 [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
` (16 preceding siblings ...)
2013-04-27 12:32 ` [Bug target/56866] [4.7/4.8/4.9 Regression] " jakub at gcc dot gnu.org
@ 2013-04-29 16:08 ` winfried.magerl@t-online.de
17 siblings, 0 replies; 19+ messages in thread
From: winfried.magerl@t-online.de @ 2013-04-29 16:08 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread