Christophe Lyon <christophe.l...@linaro.org> writes: > On Thu, 15 Apr 2021 at 17:19, Richard Sandiford via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: >> >> A lot of the SVE assembly tests are for generic-tuned SVE codegen >> and so can fail when run on a toolchain configured with --with-cpu. >> >> This could easily be solved by forcing -mtune=generic, like we already >> do for -moverride=tune=none. However, the testsuite also has some >> useful execution tests that it would be better to run with as >> few flag changes as possible. Also, the flags in $sve_flags are >> printed as part of the test results, so each change to $sve_flags >> results in a change to the test summaries. >> >> This patch instead intercepts dg-options and tailors the list >> of additional options based on what the test is trying to do. >> It also gets rid of DEFAULT_CFLAGS, which are never useful >> for these tests. >> >> Tested on an aarch64-linux-gnu toolchain configured with >> --with-cpu=a64fx, pushed to trunk. >> >> Richard > > This looks nice, I'm wondering whether something similar would help clean up > the > arm side of the testsuite where it has become a nightmare to deal with all the > cpu/fpu/float-abi combinations?
Yeah, it probably could. I wondered about trying to make it more general than just aarch64, but in the end the small size of the code and the number of AArch64-specific bits made it seem like it wouldn't be a good idea. If more targets add something similar, that might give an idea of where the common ground is. I imagine things will be more complex for arm though. FWIW, for mips.exp I used a complicated scheme to automatically infer a sequence of options based on the (usually single) feature that the test specifically needed. It ended up being way too elaborate though. I don't think any other target should replicate that. I guess arm would need something in between the two in terms of complexity. Thanks, Richard
