]> git.ipfire.org Git - thirdparty/gcc.git/commit
[RISC-V][PR target/118934] Fix ICE in RISC-V long branch support
authorJeff Law <jlaw@ventanamicro.com>
Sun, 2 Mar 2025 19:08:34 +0000 (12:08 -0700)
committerJeff Law <jlaw@ventanamicro.com>
Sun, 2 Mar 2025 19:10:36 +0000 (12:10 -0700)
commit67e824c2497176980cb0c5d14bc730fa4ce2e1ad
treefd175dc6a38d6be198a00a86fc7fb5dec8541ca0
parent585aa4065f1028c2fbfab55462e5e5e6b3c208c4
[RISC-V][PR target/118934] Fix ICE in RISC-V long branch support

I'm not sure if I goof'd this or if I merely upstreamed someone else's goof.
Either way the long branch code isn't working correctly.

We were using 'n' as the output modifier to negate the condition.  But 'n' has
a special meaning elsewhere, so when presented with a condition rather than
what was expected, boom, the compiler ICE'd.

Thankfully there's only a few places where we were using %n which I turned into
%r.

The BZ entry includes a good testcase, it just takes a long time to compile as
it's trying to create the out-of-range scenario.  I'm not including the
testcase due to how long it takes, but I did test it locally to ensure it's
working properly now.

I'm sure that with a little bit of work I could create at testcase that worked
before and fails with the trunk (by taking advantage of the fuzzyness in length
computations).  So I'm going to consider this a regression.

Will push to the trunk after pre-commit testing does its thing.

PR target/118934
gcc/
* config/riscv/corev.md (cv_branch): Adjust output template.
(branch): Likewise.
* config/riscv/riscv.md (branch): Likewise.
* config/riscv/riscv.cc (riscv_asm_output_opcode): Handle 'r' rather
than 'n'.
gcc/config/riscv/corev.md
gcc/config/riscv/riscv.cc
gcc/config/riscv/riscv.md