https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122051
--- Comment #2 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:c34ccc8ba23aa7cbf5e2d88186abf0c384a675a3 commit r16-4185-gc34ccc8ba23aa7cbf5e2d88186abf0c384a675a3 Author: Jeff Law <[email protected]> Date: Thu Oct 2 06:25:47 2025 -0600 [RISC-V][PR target/122051] Fix pmode_reg_or_uimm5_operand for thead vector For this bug we're failing during vsetvl insertion, but the real problem happens earlier. Basically the slide instructions are using pmode_reg_or_uimm5_operand which has an implementation that was appropriate when we integrated RVV, but which is bogus once thead vector was added. It was just a thin wrapper around vector_length_operand. vector_length_operand rejects most constants when thead vector is enabled. LRA saw the rK constraint, so it figured the (const_int 1) was a sensible substitution for the relevant operand. It was only during vsetvl insertion that we made another change to the insn and tried to recognize it and boom things blew up. This patch makes pmode_reg_or_uimm5_operand independent of vector_length_operand and everything is happy again. Tested on riscv32-elf (verifying the selector properly skips the test) and riscv64-elf where the ICE could be seen. Bootstrap on the Pioneer and BPI just started a short while ago, so no data for another 7/24 hours respectively, but not expecting issues. PR target/122051 gcc/ * config/riscv/predicates.md (pmode_reg_or_uimm5_operand): Implement directly rather than using vector_length_operand. gcc/testsuite/ * gcc.target/riscv/pr122051.c: New test.
