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
>
