Hi,
looks like XOP/FAM4/FAM is responsible for the additional errors I
see when running gcc-testsuite or glibc-testsuite. I've opened Bug
56866 as a starting point, so the subject is a little bit misleading:
Bug 56866 - gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles
glibc-2.17/crypt/sha512.c
Disabling XOP/FAM4/FAM shows no regression (compared with amdfam10) with
glibc-testsuite and no additional execution-errors in the gcc-testsuite.
Currently I'm running gcc-4.8-branch configured ith '--with-arch=bdver2'
and with a simple patch disabling XOP/FAM4/FAM for bdver2 in
gcc/config/i386/i386.c.
regards
winfried
On Mon, Apr 01, 2013 at 08:44:59PM +0200, winfried.mag...@t-online.de wrote:
Hi,
replacing my AMD Phenom2 with a AMD Piledriver (Bulldozer Version2)
was reason enough for me to recompile gcc (and the whole linux-system)
with hard optimisation set to bdver2 (as I've done since my first
linux on an 68030).
But this time an increasing number of errors makes me a little bit nervous
and after some additional errors when running the glibc-2.17-testsuite
I've refused to use this optimisation as default on my system.
The results might be interesting for the gcc-developer-community and I've
mailed four results with different set of '--with-arch' and '--with-tune'
to gcc-testresu...@gcc.gnu.org from stock gcc-4.8.0.
I've set '--build=x86_64-winnix-linux-gnu' just to make it easier to search
the archive for this specific results (results include the complete set
of relevant libs/tools).
Basic flags for every compile/test-run:
--build=x86_64-winnix-linux-gnu --enable-languages=c,c++ --enable-shared
--prefix=/usr --enable-multilib=no
optimization for phenom2 (I've used since I've replaced
my Athlon-FX):
--with-arch=amdfam10 --with-tune=amdfam10
soft-optimization for bdver2 which is the current configuration
I use on my system (no additional errors in glibc-2.17:
--with-arch=amdfam10 --with-tune=bdver2
optimization for bdver2:
--with-arch=bdver2 --with-tune=bdver2
The number of additional errors is always increasing. Mostly errors
in scan-assembler and scan-tree-dump (maybe wrong expections in the
tests?) but with arch=bdver2 I see an increasing number of
execution-tests failing.
Surprisingly (at least for me) the difference is only visible in the
gcc-testsuite and doesn't harm other languages.
I've done some work to ensure errors are not related to the system-setup
and maybe it's of interest what I've learned during this process:
gcc.dg/guality/vla-1.c and vla-2.c depends on the gdb-version. Fails
with stock gdb-7.5.1 (also tested prerelease gdb-7.5.91) and don't
fail with gdb-patches from opensuse (fedora-patches works also).
Using tcl8.6.0 as base for expect/dejagnu doesn't currently work,
at least not with the gcc-testsuite.
Please note that this is not a regression and that gcc-4.7.x gives
very similar results.
Thank you for listening and all the good work I apreciate since
20 years with all sorts of cpu's and operating-systems gcc
supports!
best regards
winfried
