On Tue, Apr 26, 2022 at 04:45:14PM +0100, Andre Vieira (lists) wrote:
> For some reason I thought richi wasn't able to reproduce this on other
> targets, but from my last read of the PR I think he was... Regardless
Note, it isn't strictly needed that a test added as generic test
fails before fixes on all arches or many of them, when a test is
itself not target specific, it can be useful to run it on all targets,
while it will catch regressing the same bug again on the originally
failing target, sometimes it can catch other bugs on other targets
(happened many times in the past).
> probably worth testing it for all targets for sure.
> Question is how do I make it run for all targets but use target specific
> options for each to try and trigger the original issue? Multiple
> dg-additional-options with different target selectors?
Yes. But they really need to be guarded also by effective targets
which guarantee hw support.
Say if you /* { dg-additional-options "-mavx2" }
then it would need to be
/* { dg-additional-options "-mavx2" { target { { i?86-* x86_64-* } &&
avx2_runtime } } } */
or so where that effective target ensures both that assembler can assemble
avx2 instructions and that the hw it is tested on does support them too.
No idea about aarch64/arm effective targets.
Another way sometimes used is to place just normal test without magic
options into gcc.dg/vect/ , i.e. test that with whatever options user
configured gcc with or asks through RUNTESTFLAGS, and when needed add
gcc.target/*/ additional test that has extra dg-options and renames main
to something else and calls that only after checking hw capabilities.
grep ../../gcc.dg/vect testsuite/gcc.target/i386/*.c
for some examples.
Jakub
