Launchpad has imported 18 comments from the remote bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123092.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://documentation.ubuntu.com/launchpad/user/reference/bugs/multi-project-bugs/about-multi-project-bugs/#bugs-in-external-trackers. ------------------------------------------------------------------------ On 2025-12-11T06:33:01+00:00 Heinrich Schuchardt wrote: Created attachment 63034 Crash output Kamailio is a package in Ubuntu 26.04. Building on riscv64 with RVA23 fails t_lookup.c:1667:1: internal compiler error: in extract_constrain_insn, at recog.cc:2783 See appended preprocessed source. Similar problems have been reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119208 "internal compiler error: in extract_constrain_insn, at recog.cc:2783" and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122438 [m68k] internal compiler error: in extract_constrain_insn, at recog.cc:2783 Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/3 ------------------------------------------------------------------------ On 2025-12-11T06:52:24+00:00 Pinskia wrote: // t_lookup.c:1667:1: error: insn does not satisfy its constraints: // 1667 | } // | ^ // (insn 322 326 323 21 (prefetch (plus:DI (mem/f:DI (plus:DI (reg/f:DI 9 s1 [orig:1233 p_msg ] [1233]) // (const_int 504 [0x1f8])) [2 p_msg_509(D)->unparsed+0 S8 A64]) // (const_int 64 [0x40])) // (const_int 0 [0]) // (const_int 1 [0x1])) "t_lookup.c":1587:4 487 {prefetch} // (nil)) Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/5 ------------------------------------------------------------------------ On 2025-12-11T06:55:42+00:00 Pinskia wrote: F Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/6 ------------------------------------------------------------------------ On 2025-12-11T06:59:25+00:00 Pinskia wrote: (In reply to Andrew Pinski from comment #2) > F Ignore this comment, I was going to type "fixed" but I was mixing up the dates for GCC 15.2.0 release and the fix for PR 118241. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/7 ------------------------------------------------------------------------ On 2025-12-11T07:12:09+00:00 Pinskia wrote: On the trunk we get: ``` during RTL pass: final t_lookup.c: In function ‘t_check_msg’: t_lookup.c:1667:1: internal compiler error: in riscv_print_operand_address, at config/riscv/riscv.cc:8213 0x40ac60c internal_error(char const*, ...) ../../gcc/diagnostic-global-context.cc:787 0x40baf2b fancy_abort(char const*, int, char const*) ../../gcc/diagnostics/context.cc:1805 0x21fb9df riscv_print_operand_address ../../gcc/config/riscv/riscv.cc:8213 0x16bead3 output_address(machine_mode, rtx_def*) ../../gcc/final.cc:3667 0x16be3e5 output_asm_insn(char const*, rtx_def**) ../../gcc/final.cc:3524 0x16bce8c final_scan_insn_1 ../../gcc/final.cc:2856 0x16bd062 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) ../../gcc/final.cc:2902 0x16baefa final_1 ../../gcc/final.cc:1984 0x16bfca4 rest_of_handle_final ../../gcc/final.cc:4260 0x16c0002 execute ../../gcc/final.cc:4338 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. ``` Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/8 ------------------------------------------------------------------------ On 2025-12-11T07:15:48+00:00 Pinskia wrote: Reduced options: `-O2 -march=rv64gcb_zicbop -mabi=lp64d `. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/9 ------------------------------------------------------------------------ On 2025-12-11T07:52:06+00:00 Pinskia wrote: Reduced testcase: ``` struct a { char *b; } d; int e; int c(struct a *); void f() { __builtin_prefetch(d.b + 64); if (e) c(&d); } ``` `-O2 -march=rv64gc_zicbop -mabi=lp64d`. Confirmed. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/10 ------------------------------------------------------------------------ On 2025-12-18T17:42:41+00:00 Vineetg-o wrote: Gave Andrew's test a spin With IRA things seem ok: There's an address computation and the prefetch ``` (insn 6 9 12 2 (set (reg/f:DI 139 [ d.b ]) (mem/f/c:DI (lo_sum:DI (reg/f:DI 137) (symbol_ref:DI ("d") [flags 0x86] <var_decl 0x703ee5bc5be0 d>)) [1 d.b+0 S8 A64])) {*movdi_64bit} (expr_list:REG_EQUIV (mem/f/c:DI (lo_sum:DI (reg/f:DI 137) (symbol_ref:DI ("d") [flags 0x86] <var_decl 0x703ee5bc5be0 d>)) [1 d.b+0 S8 A64]) (expr_list:REG_EQUAL (mem/f/c:DI (symbol_ref:DI ("d") [flags 0x86] <var_decl 0x703ee5bc5be0 d>) [1 d.b+0 S8 A64]) (nil)))) (insn 8 12 13 2 (prefetch (plus:DI (reg/f:DI 139 [ d.b ]) (const_int 64 [0x40])) (const_int 0 [0]) (const_int 3 [0x3])) {prefetch} (expr_list:REG_DEAD (reg/f:DI 139 [ d.b ]) (nil))) ``` LRA then decided to fold the addr computation into prefetch itself ``` Removing equiv init insn 6 (freq=1000) 6: r139:DI=[r137:DI+low(`d')] REG_EQUIV [r137:DI+low(`d')] REG_EQUAL [`d'] deleting insn with uid = 6. Considering alt=0 of insn 12: (0) =r (1) r Choosing alt 0 in insn 8: (0) Qr (1) i (2) n {prefetch} (insn 8 12 13 2 (prefetch (plus:DI (mem/f/c:DI (lo_sum:DI (reg/f:DI 10 a0 [137]) (symbol_ref:DI ("d") [flags 0x86] <var_decl 0x703ee5bc5be0 d>)) [1 d.b+0 S8 A64]) (const_int 64 [0x40])) (const_int 0 [0]) (const_int 3 [0x3])) {prefetch} (nil)) ``` Which is what eventually ICE in final pass. I initially thought this was a regression from my prev patch in the area with relaxing the constraint to "Qr" to allow reloads, but removing the "r" experimentally doesn't fix this. The preetch pattern as defined allows PLUS but then requires operand0 to be a register, but it seems LRA is not honoring that for some reason. Haven't looked into why LRA is doing this. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/11 ------------------------------------------------------------------------ On 2026-01-12T20:49:44+00:00 Bergner-gcc wrote: (In reply to Vineet Gupta from comment #7) > The preetch pattern as defined allows PLUS but then requires operand0 to be > a register, but it seems LRA is not honoring that for some reason. > > Haven't looked into why LRA is doing this. The prefetch pattern looks like: (define_insn "prefetch" [(prefetch (match_operand 0 "prefetch_operand" "Qr,ZD") (match_operand 1 "imm5_operand" "i,i") (match_operand 2 "const_int_operand" "n,n"))] "TARGET_ZICBOP || TARGET_XMIPSCBOP" ... The Qr constraint correctly rejects the (plus:DI (mem...)) operand. LRA then checks if there is another alternative that works, so it tries the ZD constraint. I would have assumed that MIPS specific constraint would reject everything when we're not compiling for MIPS CBOP, but it doesn't and actually accepts this address. I assume we'd want to change the ZD constraint to be defined like so? (define_address_constraint "ZD" "An address operand that is valid for a mips prefetch instruction" - (match_test "riscv_prefetch_offset_address_p (op, mode)")) + (match_test "TARGET_XMIPSCBOP && riscv_prefetch_offset_address_p (op, mode)")) However, even doing that, we still ICE, but with a slightly better error message: pr123092.i:10:1: error: insn does not satisfy its constraints: 10 | } | ^ (insn 8 12 13 2 (prefetch (plus:DI (mem/f/c:DI (lo_sum:DI (reg/f:DI 10 a0 [137]) (symbol_ref:DI ("d") [flags 0x86] <var_decl 0x7f68cc52e000 d>)) [1 d.b+0 S8 A64]) (const_int 64 [0x40])) (const_int 0 [0]) (const_int 3 [0x3])) "pr123092.i":7:3 500 {prefetch} (nil)) during RTL pass: reload ...so the same bad insn, we just end up catching it earlier than without the change to the ZD constraint. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/12 ------------------------------------------------------------------------ On 2026-01-14T21:29:31+00:00 Cvs-commit wrote: The master branch has been updated by Peter Bergner <[email protected]>: https://gcc.gnu.org/g:58977d739238d927c02f64c6417c887df86a5f55 commit r16-6785-g58977d739238d927c02f64c6417c887df86a5f55 Author: Peter Bergner <[email protected]> Date: Wed Jan 14 15:12:21 2026 -0600 RISC-V: Enable the ZD constraint only when xmipscbop is enabled [PR123092] The ZD constraint is specific to the mips prefetch instruction. It is currently always enabled, leading to ICEs when xmipscbop is disabled. Solved by only enabling the ZD constraint whenever xmipscbop is enabled. 2026-01-14 Peter Bergner <[email protected]> gcc/ PR target/123092 * config/riscv/constraints.md (ZD): Disable when xmipscbop is disabled. Signed-off-by: Peter Bergner <[email protected]> Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/13 ------------------------------------------------------------------------ On 2026-01-14T21:30:25+00:00 Bergner-gcc wrote: The above commit is only a partial fix. There is more to do to fix this entirely. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/14 ------------------------------------------------------------------------ On 2026-01-14T22:21:10+00:00 Law-6 wrote: So as I hinted at on Tuesday, the LRA code is making changes to the relevant insn without checking for the validity of those changes. However, it's happening through a path I'm not familiar with. In particular here: if (curr_insn_transform (false)) changed_p = true; /* Check non-transformed insns too for equiv change as USE or CLOBBER don't need reloads but can contain pseudos being changed on their equivalences. */ else if (bitmap_bit_p (equiv_insn_bitmap, INSN_UID (curr_insn)) && loc_equivalence_change_p (&PATTERN (curr_insn))) { lra_update_insn_regno_info (curr_insn); changed_p = true; } THe incoming form as we call curr_insn_transform is: (insn 8 12 13 2 (prefetch (plus:DI (reg/f:DI 139 [ d.b ]) (const_int 64 [0x40])) (const_int 0 [0]) (const_int 3 [0x3])) "j.c":7:3 500 {prefetch} (expr_list:REG_DEAD (reg/f:DI 139 [ d.b ]) (nil))) Obviously we have a pseudo in there. Note we don't have any naked USE/CLOBBERs. curr_insn_transform returns false (at least one alternative fits), but no changes are made by curr_insn_transform. Then loc_equivalence_change_p does its thing resulting in: (insn 8 12 13 2 (prefetch (plus:DI (mem/f/c:DI (lo_sum:DI (reg/f:DI 137) (symbol_ref:DI ("d") [flags 0x86] <var_decl 0x7ffff73c5be0 d>)) [1 d.b+0 S8 A64]) (const_int 64 [0x40])) (const_int 0 [0]) (const_int 3 [0x3])) "j.c":7:3 500 {prefetch} (expr_list:REG_DEAD (reg/f:DI 139 [ d.b ]) (nil))) At which point the form hangs around forever and results in the failure we're seeing. We do _not_ get back into curr_insn_transform for this insn to try and reload it. If I hack up loc_equivalence_change_p to do nothing for this insn then we replace the pseudo with its MEM equivalence. We then reload the operand of the prefetch into a new register (via a subsequent call to curr_insn_transform) and the right things just happen. Vlad -- how is this supposed to work? It seems wrong to be slamming in the equivalence without either validating the result to verify its valid or sending it back through curr_insn_transform to reload the invalid stuff. Interesting enough Robin has a similar issue in play where we slam in a constant equivalence for a register resulting in an invalid insn. I suspect, but haven't yet confirmed that its the same basic path we're seeing here. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/15 ------------------------------------------------------------------------ On 2026-01-14T22:58:27+00:00 Bergner-gcc wrote: (In reply to Jeffrey A. Law from comment #11) > So as I hinted at on Tuesday, the LRA code is making changes to the relevant > insn without checking for the validity of those changes. > > However, it's happening through a path I'm not familiar with. In particular > here: > > if (curr_insn_transform (false)) > changed_p = true; > /* Check non-transformed insns too for equiv change as USE > or CLOBBER don't need reloads but can contain pseudos > being changed on their equivalences. */ > else if (bitmap_bit_p (equiv_insn_bitmap, INSN_UID (curr_insn)) > && loc_equivalence_change_p (&PATTERN (curr_insn))) > { > lra_update_insn_regno_info (curr_insn); > changed_p = true; > } Heh, yes, I debugged it to this path as well and confirm we never revisit the insn after forcing in the equivalence without checking it against any constraints. I agree with you, I'd like Vlad's input on how this is supposed to work. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/16 ------------------------------------------------------------------------ On 2026-01-15T19:58:47+00:00 Vmakarov-4 wrote: > Vlad -- how is this supposed to work? It seems wrong to be slamming in the > equivalence without either validating the result to verify its valid or > sending it back through curr_insn_transform to reload the invalid stuff. > The equivalence change should result in processing the insn on its constraints again. And in this case it did not happen. I've reproduced the bug. I think the fix will be ready tomorrow. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/17 ------------------------------------------------------------------------ On 2026-01-16T15:12:50+00:00 Cvs-commit wrote: The master branch has been updated by Vladimir Makarov <[email protected]>: https://gcc.gnu.org/g:538177d9b4c48321e07e1fd5647ed960049288f8 commit r16-6821-g538177d9b4c48321e07e1fd5647ed960049288f8 Author: Vladimir N. Makarov <[email protected]> Date: Fri Jan 16 10:09:52 2026 -0500 [PR123092, LRA]: Reprocess insn after equivalence substitution LRA in the test case substituted equivalence in an insn but did not process the insn on satisfying constraints after that. It resulted in error "insn does not satisfy its constraints" gcc/ChangeLog: PR target/123092 * lra-constraints.cc (lra_constraints): Push insn on processing stack after equivalence substitution. gcc/testsuite/ChangeLog: PR target/123092 * gcc.target/riscv/pr123092.c: New. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/19 ------------------------------------------------------------------------ On 2026-01-16T15:17:47+00:00 Vmakarov-4 wrote: I believe the patch is safe to commit it to the previous release branches but I'd like to wait a bit and commit it to the branches on the next week. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/20 ------------------------------------------------------------------------ On 2026-01-19T18:29:44+00:00 Cvs-commit wrote: The releases/gcc-15 branch has been updated by Jeff Law <[email protected]>: https://gcc.gnu.org/g:14da7fd501f7993c18f096e7c97216b1779e1e63 commit r15-10707-g14da7fd501f7993c18f096e7c97216b1779e1e63 Author: Vladimir N. Makarov <[email protected]> Date: Fri Jan 16 10:09:52 2026 -0500 [PR123092, LRA]: Reprocess insn after equivalence substitution LRA in the test case substituted equivalence in an insn but did not process the insn on satisfying constraints after that. It resulted in error "insn does not satisfy its constraints" gcc/ChangeLog: PR target/123092 * lra-constraints.cc (lra_constraints): Push insn on processing stack after equivalence substitution. gcc/testsuite/ChangeLog: PR target/123092 * gcc.target/riscv/pr123092.c: New. (cherry picked from commit 538177d9b4c48321e07e1fd5647ed960049288f8) Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/21 ------------------------------------------------------------------------ On 2026-01-19T18:31:34+00:00 Law-6 wrote: Cherry-picked Vlad's patch. We don't need Peter's patch because we don't have P8700 support in gcc-15. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-15/+bug/2134383/comments/22 ** Changed in: gcc Status: Unknown => Fix Released ** Changed in: gcc Importance: Unknown => Medium ** Bug watch added: GCC Bugzilla #122438 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122438 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2134383 Title: internal compiler error: in extract_constrain_insn To manage notifications about this bug go to: https://bugs.launchpad.net/gcc/+bug/2134383/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
