https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64115
Ulrich Weigand <uweigand at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dje.gcc at gmail dot com --- Comment #3 from Ulrich Weigand <uweigand at gcc dot gnu.org> --- The ICE is triggered by checking code in rs6000_delegitimize_address: if (GET_CODE (y) == UNSPEC && XINT (y, 1) == UNSPEC_TOCREL) { #ifdef ENABLE_CHECKING if (REG_P (XVECEXP (y, 0, 1)) && REGNO (XVECEXP (y, 0, 1)) == TOC_REGISTER) { /* All good. */ } else if (GET_CODE (XVECEXP (y, 0, 1)) == DEBUG_EXPR) { /* Weirdness alert. df_note_compute can replace r2 with a debug_expr when this unspec is in a debug_insn. Seen in gcc.dg/pr51957-1.c */ } else { debug_rtx (orig_x); abort (); } #endif which attempts to ensure that the second argument of UNSPEC_TOCREL is the TOC register. However, this check seems fragile; in debug code, we can get RTX simplifications that replace the TOC register by some equivalent expression. The code already recognizes one such case; this bug shows another case, where the TOC register is replaced by a MEM RTX for the TOC save slot holding the TOC value. [ This case is probably made more likely by the change in my ELFv2 ABI preparation patch, which has the effect of making TOC moves into the save slot more explicit at the RTL level, allowing var-tracking code to detect that equivalence. ] One could try to make this check in rs6000_delegitimize_address more generic by allowing some (or all) MEM RTXes. However, I'm wonding what exactly that check is supposed to achieve in the first place; for the purposes of this routine, the second argument of UNSPEC_TOCREL is really irrelevant. David, would you be OK with simply removing the check (everything enclosed with ENABLE_CHECKING in the above code)?