https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118934
--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jeff Law <l...@gcc.gnu.org>: https://gcc.gnu.org/g:67e824c2497176980cb0c5d14bc730fa4ce2e1ad commit r15-7787-g67e824c2497176980cb0c5d14bc730fa4ce2e1ad Author: Jeff Law <j...@ventanamicro.com> Date: Sun Mar 2 12:08:34 2025 -0700 [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'.
