https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105192
Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2022-11-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Something like this might fix the issue: apinski@xeond:~/src/upstream-gcc/gcc/gcc$ git diff config/mips/mips.md diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md index e0f0a582732..3419f4df307 100644 --- a/gcc/config/mips/mips.md +++ b/gcc/config/mips/mips.md @@ -1217,7 +1217,7 @@ (define_expand "ctrap<mode>4" [(match_operand:GPR 1 "reg_or_0_operand") (match_operand:GPR 2 "arith_operand")]) (match_operand 3 "const_0_operand"))] - "ISA_HAS_COND_TRAPI || ISA_HAS_COND_TRAP" + "can_create_pseudo_p () && (ISA_HAS_COND_TRAPI || ISA_HAS_COND_TRAP") { mips_expand_conditional_trap (operands[0]); DONE; I have no way to test it though. But what is happening from the backtrace and where the assert is: * the post-reload ifcvt is detecting a conditional trap and the mips backend didn't expect any post-reload (really !can_create_pseudo_p ()) detection of a condtional trap happening so it thought it could use force_reg (which might create a new pseudo register).