aboutsummaryrefslogtreecommitdiff
path: root/libcpp/files.c
diff options
context:
space:
mode:
authorJeff Law <jlaw@ventanamicro.com>2025-10-02 06:25:47 -0600
committerJeff Law <jlaw@ventanamicro.com>2025-10-02 06:25:47 -0600
commitc34ccc8ba23aa7cbf5e2d88186abf0c384a675a3 (patch)
treeb1fdbd27422778765681e37ddc4232dbd52dd6ba /libcpp/files.c
parent264a575765e0985fdc8a00b16c1d5bb4a46ed4db (diff)
downloadgcc-c34ccc8ba23aa7cbf5e2d88186abf0c384a675a3.zip
gcc-c34ccc8ba23aa7cbf5e2d88186abf0c384a675a3.tar.gz
gcc-c34ccc8ba23aa7cbf5e2d88186abf0c384a675a3.tar.bz2
[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.
Diffstat (limited to 'libcpp/files.c')
0 files changed, 0 insertions, 0 deletions