This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
increasing testsuite-errors when optimizing for amdfam10/bdver2
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-testresults@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