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.
Or we could just add -march=unset to let the compiler apply the default
arch for the cpu. That would cancel out the explicit -march=*32* you're
testing with, and refrain from testing these two cases in 32-bit mode.
I'm not sure how important that would be. Also, I don't recall by heart
whether options added in "multilib" testing are added before or after
test-given options to be sure it would actually fix it; we don't do much
of that kind of testing. Something to check after I catch some sleep...
I think the unset stuff is new, it'd probably be OK for the trunk, but
may not work on gcc-15.
If these lines of thought make sense to you and you'd rather beat me to
fixing these, please be my guest ;-) But please let me know, otherwise
I'll end up looking into it tomorrow. Err, today.
Probably won't get to it today, got too many meetings to attend.
Anyhow, sorry about the breakage.
No worries. It's minor and clearly not a code correctness issue, ICE or
the like. It's just testsuite management (still important, but not
something that's going to cause end user code to blow up in new and
exciting ways).
Jeff
