https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302
--- Comment #9 from Alexandre Oliva <aoliva at gcc dot gnu.org> --- Thanks, this alternate testcase confirms my suspicion that the original issue was only going latent. It's clearly a preexisting register allocation issue on riscv, that was latent and that -fharden-compares exposed rather than introduced. If I understand correctly its pervasiveness, it may very well make -fharden-compares too risky to use on riscv, so I may be on the hook to fix it regardless. ISTM that a post-reload insn_and_split would at least avoid the problem. Is there any reason why this approach is not in use on riscv?
