> > > On 2/5/2026 9:26 PM, Alexandre Oliva wrote: >> On Feb 6, 2026, Jeffrey Law <[email protected]> wrote: >> >>> The fact that there are so many damn extensions means that real >>> coverage is virtually impossible. >> *nod* >> >>> BUt you're also clearly doing something different in your testing >> Yeah, maybe the difference is that we're (also) testing riscv32-elf >> builds. That's where the problems came up. > Those failures I relayed where from a riscv32-elf build. But I test it > with an additional -march flag to enable vector since that was a gap at > the time I set this thing up. It's part of what makes me wonder if the > interactions between -mcpu and -march are causing some of these headaches. > > > > >> >> Unfortunately, it looks like riscv32-elf is not equivalent to >> riscv64-elf with an explicit -march=*32*: I guess the -mcpu in the tests >> overrides the base arch in the former case, but not in the latter. > Right. That's precisely what I'm referring to. IIRC we decided to be > compatible behavior-wise with LLVM on this and it's caused similar > surprises/headaches. > >> >> If that theory is correct, I guess we should use explicit arch and abi >> options to not leave this to chance, but maybe the arch (and abi) >> options below need tuning for the tests to exercise the intended >> features. riscv-cores.def has monster arch lines for these cpus, and >> I'm hesitant to just copy those. > I was starting to lean towards that as well. I probably wouldn't try to > do the full architecture string. I'd have to review the bzs, but odds > are it's just one extension that's necessary to trigger.
I haven't followed the discussion closely but I suppose -march=ascalon (or whatever those tests use) doesn't help either? It would at least help avoid the copying of the 5-line arch strings. -- Regards Robin
