Comments

If you build an x86_64 toolchain with --with-arch enabling various
instruction set extensions by default, this causes some tests to fail
that aren't expecting those extensions to be enabled. This patch
fixes various tests failing like that for an x86_64-linux-gnu
toolchain configured --with-arch=bdver3, generally by using
appropriate -mno-* options in the tests, or in the case of
gcc.dg/pr45416.c by adjusting the scan-assembler to allow the
alternative instruction that gets used in this case. It's quite
likely other such failures appear for other --with-arch choices.
Tested x86_64-linux-gnu. OK to commit?
In addition to the failures fixed by this patch, there are many
gcc.dg/vect tests where having additional vector extensions enabled
breaks their expectations; I'm not sure of the best way to handle
those. And you get
FAIL: gcc.target/i386/avx512f-vfmaddXXXpd-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-vfmaddXXXps-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-vfmaddsubXXXpd-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-vfmaddsubXXXps-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-vfmsubXXXpd-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-vfmsubXXXps-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-vfmsubaddXXXpd-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-vfmsubaddXXXps-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-vfnmaddXXXpd-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-vfnmaddXXXps-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-vfnmsubXXXpd-2.c (test for excess errors)
FAIL: gcc.target/i386/avx512f-vfnmsubXXXps-2.c (test for excess errors)
which are assembler errors such as "operand type mismatch for
`vfmaddpd'" - it looks like the compiler isn't really prepared for the
-mavx512f -mfma4 combination, but I'm not sure what the best way to
handle it is (producing invalid output doesn't seem right, however).
If you test with -march=bdver3 in the multilib options (runtest
--target_board=unix/-march=bdver3) rather than as the configured
default, you get extra failures for the usual reason of multilib
options going after the options from dg-options (which I propose to
address in the usual way using dg-skip-if for -march= options
different from the one present in dg-options).
2014-03-28 Joseph Myers <joseph@codesourcery.com>
* gcc.dg/pr45416.c: Allow bextr on x86.
* gcc.target/i386/fma4-builtin.c, gcc.target/i386/fma4-fma-2.c,
gcc.target/i386/fma4-fma.c, gcc.target/i386/fma4-vector-2.c,
gcc.target/i386/fma4-vector.c: Use -mno-fma.
* gcc.target/i386/l_fma_double_1.c,
gcc.target/i386/l_fma_double_2.c,
gcc.target/i386/l_fma_double_3.c,
gcc.target/i386/l_fma_double_4.c,
gcc.target/i386/l_fma_double_5.c,
gcc.target/i386/l_fma_double_6.c, gcc.target/i386/l_fma_float_1.c,
gcc.target/i386/l_fma_float_2.c, gcc.target/i386/l_fma_float_3.c,
gcc.target/i386/l_fma_float_4.c, gcc.target/i386/l_fma_float_5.c,
gcc.target/i386/l_fma_float_6.c: Use -mno-fma4.
* gcc.target/i386/pr27971.c: Use -mno-tbm.
* gcc.target/i386/pr42542-4a.c: Use -mno-avx.
* gcc.target/i386/pr59390.c: Use -mno-fma -mno-fma4.

On Fri, Mar 28, 2014 at 2:46 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> If you build an x86_64 toolchain with --with-arch enabling various> instruction set extensions by default, this causes some tests to fail> that aren't expecting those extensions to be enabled. This patch> fixes various tests failing like that for an x86_64-linux-gnu> toolchain configured --with-arch=bdver3, generally by using> appropriate -mno-* options in the tests, or in the case of> gcc.dg/pr45416.c by adjusting the scan-assembler to allow the> alternative instruction that gets used in this case. It's quite> likely other such failures appear for other --with-arch choices.>> Tested x86_64-linux-gnu. OK to commit?>> In addition to the failures fixed by this patch, there are many> gcc.dg/vect tests where having additional vector extensions enabled> breaks their expectations; I'm not sure of the best way to handle> those. And you get>> FAIL: gcc.target/i386/avx512f-vfmaddXXXpd-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfmaddXXXps-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfmaddsubXXXpd-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfmaddsubXXXps-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfmsubXXXpd-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfmsubXXXps-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfmsubaddXXXpd-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfmsubaddXXXps-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfnmaddXXXpd-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfnmaddXXXps-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfnmsubXXXpd-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfnmsubXXXps-2.c (test for excess errors)>> which are assembler errors such as "operand type mismatch for> `vfmaddpd'" - it looks like the compiler isn't really prepared for the> -mavx512f -mfma4 combination, but I'm not sure what the best way to> handle it is (producing invalid output doesn't seem right, however).>> If you test with -march=bdver3 in the multilib options (runtest> --target_board=unix/-march=bdver3) rather than as the configured> default, you get extra failures for the usual reason of multilibhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=59971
This is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59971
> options going after the options from dg-options (which I propose to> address in the usual way using dg-skip-if for -march= options> different from the one present in dg-options).
Here is a patch:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01891.html

On Fri, Mar 28, 2014 at 10:46 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> If you build an x86_64 toolchain with --with-arch enabling various> instruction set extensions by default, this causes some tests to fail> that aren't expecting those extensions to be enabled. This patch> fixes various tests failing like that for an x86_64-linux-gnu> toolchain configured --with-arch=bdver3, generally by using> appropriate -mno-* options in the tests, or in the case of> gcc.dg/pr45416.c by adjusting the scan-assembler to allow the> alternative instruction that gets used in this case. It's quite> likely other such failures appear for other --with-arch choices.>> Tested x86_64-linux-gnu. OK to commit?>> In addition to the failures fixed by this patch, there are many> gcc.dg/vect tests where having additional vector extensions enabled> breaks their expectations; I'm not sure of the best way to handle> those. And you get>> FAIL: gcc.target/i386/avx512f-vfmaddXXXpd-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfmaddXXXps-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfmaddsubXXXpd-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfmaddsubXXXps-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfmsubXXXpd-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfmsubXXXps-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfmsubaddXXXpd-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfmsubaddXXXps-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfnmaddXXXpd-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfnmaddXXXps-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfnmsubXXXpd-2.c (test for excess errors)> FAIL: gcc.target/i386/avx512f-vfnmsubXXXps-2.c (test for excess errors)>> which are assembler errors such as "operand type mismatch for> `vfmaddpd'" - it looks like the compiler isn't really prepared for the> -mavx512f -mfma4 combination, but I'm not sure what the best way to> handle it is (producing invalid output doesn't seem right, however).
I will look into these.
> If you test with -march=bdver3 in the multilib options (runtest> --target_board=unix/-march=bdver3) rather than as the configured> default, you get extra failures for the usual reason of multilib> options going after the options from dg-options (which I propose to> address in the usual way using dg-skip-if for -march= options> different from the one present in dg-options).>> 2014-03-28 Joseph Myers <joseph@codesourcery.com>>> * gcc.dg/pr45416.c: Allow bextr on x86.> * gcc.target/i386/fma4-builtin.c, gcc.target/i386/fma4-fma-2.c,> gcc.target/i386/fma4-fma.c, gcc.target/i386/fma4-vector-2.c,> gcc.target/i386/fma4-vector.c: Use -mno-fma.> * gcc.target/i386/l_fma_double_1.c,> gcc.target/i386/l_fma_double_2.c,> gcc.target/i386/l_fma_double_3.c,> gcc.target/i386/l_fma_double_4.c,> gcc.target/i386/l_fma_double_5.c,> gcc.target/i386/l_fma_double_6.c, gcc.target/i386/l_fma_float_1.c,> gcc.target/i386/l_fma_float_2.c, gcc.target/i386/l_fma_float_3.c,> gcc.target/i386/l_fma_float_4.c, gcc.target/i386/l_fma_float_5.c,> gcc.target/i386/l_fma_float_6.c: Use -mno-fma4.> * gcc.target/i386/pr27971.c: Use -mno-tbm.> * gcc.target/i386/pr42542-4a.c: Use -mno-avx.> * gcc.target/i386/pr59390.c: Use -mno-fma -mno-fma4.
OK.
Thanks,
Uros.