https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122147
--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jeff Law <[email protected]>: https://gcc.gnu.org/g:e037693f66823c168ed7d37ae70b3cd5aa757b1e commit r16-4216-ge037693f66823c168ed7d37ae70b3cd5aa757b1e Author: Jeff Law <[email protected]> Date: Sat Oct 4 08:33:19 2025 -0600 [RISC-V][PR target/122147] Avoid creating (subreg (mem)) in RISC-V port So another fun bug. Utterly amazed we didn't trip over this in some form or another until now. We're generating a (subreg (mem)) expression during combine because "move_operand" accepts it as a valid operand. We've discouraged those kinds of expressions for a long time, even though they're generally expected to act like registers due to reloading. In this case reloading just goes into an infinite loop ð Rather than try to fix this in LRA, let's just avoiding creating the problematical subreg to begin with. That's accomplished by being a bit more selective in what move_operand allows. I'm not particularly happy with what I saw in move_operand, but I'm inclined to let it be right now. Tested on rv32 and rv64. Bootstraps on the Pioneer and BPI will run later today. I'll push once the pre-commit CI system has done its thing. PR target/122147 gcc/ * config/riscv/predicates.md (move_operand): Only allow a REG as the operand of a SUBREG. gcc/testsuite/ * gcc.target/riscv/pr122147.c: New test.
