On Jan 31, 2026, Jeffrey Law <[email protected]> wrote: >> * gcc.target/riscv/pr116715.c: Drop unchecked arch overrider. > But the whole point of the test would be a test for a bogus code > generation issue with Zbs enabled.
*nod*, I get that is the goal of the test, but between the choices of skipping the test altogether or testing that alternative codegen succeeds, for when the target cpu under test doesn't support Zbs, I can't see why the former would be preferred. Of course, when the selected cpu does support the Zbs extension, then the compiler will generate code to use it and then the test will do what it was originally meant to do. That was my reasoning anyway. Now, there is also a third case, of using a cpu for testing that supports the Zbs extension, but without telling the compiler or the test harness that it does. Even then, checking for suport and then selecting one specific arch variant, would limit the test in its coverage of other extensions that could also be exercised otherwise, whether supersets or subsets of gc_Zbs. When it comes to generic code, in my reasoning I tend to privilege increasing testing coverage and diversification over whatever arch, cpu, abi, etc the tester selects for testing, so that multiple test variants may test different aspects instead of all testing the same thing or not testing anything. But I guess there is room for different goals here. > So adding && riscv_b_ok on the target selector seems better to me. Huh. That effective target wasn't defined in gcc-15's target-supports.exp, where I looked for it, and it didn't occur to me to look for it in the trunk. Anyhow, I'll be happy to restore the preexisting options, but limit their use to when the Zbs extension is available in the cpu under test. Would you really prefer the test to be skipped altogether otherwise, or would it be ok for the options to not be applied while we'd still compile and run the test with whatever options the user selected for testing? -- Alexandre Oliva, happy hacker https://blog.lx.oliva.nom.br/ Free Software Activist FSFLA co-founder GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity. Excluding neuro-others for not behaving ""normal"" is *not* inclusive!
