On Jun 29, 2026, "Robin Dapp" <[email protected]> wrote: > Rather than adding a third option, I'd prefer regularizing the existing once > to > match what others are doing, i.e. > riscv_v -> can compiler vector (with or without added options, add options > if > necessary) > riscv_v_hw -> can execute vector
There are lots of riscv*_ok patterns that follow the riscv_v_ok exceptional pattern. Adapting all those tests was far too much work; not so much because of s/_ok$//, but because those that don't have _ok, such as riscv_v, don't add-options riscv_v, which they'd need to do once the behavior of riscv_v_ok is folded into riscv_v. So I figured an incremental approach was the only viable path to address this. I figured that meant adding a third choice, starting its adoption, and progressively phase out existing uses of riscv_v into riscv_v_ok, until they're all gone and we can mechanically replace riscv_v_ok with riscv_v_hw and riscv_v_okc with riscv_v. Other uses of *riscv*_ok procs might be thrown into the list of to-be-phased-out-and-renamed patterns. I expect this would be a long and error-prone process. Considering how often I've hit backported riscv testcases that fail in the older branches, this should also be taken into account for the phasing-out plan. It's far too much for me to tackle :-( > I realize there are tons of tests that don't follow a proper scheme but I > would > hope rewriting to be mostly mechanical? I wish! There's lack of clarity of intent in tests that require riscv_v. Presumably a mechanical rewrite into requiring riscv_v_ok and add-options riscv_v would do, but IIRC I found a number of them that overrode compile flags, which made me feel that they should be tackled by someone who knew what the tests meant to accomplish. -- 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!
