https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116199
--- Comment #7 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:cfeb994d64743691d4a787f8eef7ce52d8711756 commit r15-2710-gcfeb994d64743691d4a787f8eef7ce52d8711756 Author: Jeff Law <j...@ventanamicro.com> Date: Sun Aug 4 13:09:02 2024 -0600 [committed][PR rtl-optimization/116199] Fix latent bug in reload's SUBREG handling Building glibc on the m68k has exposed a long standing latent bug in reload. Basically ext-dce replaced an extension with a subreg expression (good) resulting in this pair of insns: > (insn 7 4 8 2 (set (reg:DI 31 [ _1 ]) > (subreg:DI (reg/v:SI 37 [ __major ]) 0)) "j.c":7:32 75 {*m68k.md:1568} > (nil)) > (insn 8 7 10 2 (set (reg:DI 39 [ _2 ]) > (ashift:DI (reg:DI 31 [ _1 ]) > (const_int 8 [0x8]))) "j.c":7:48 322 {*ashldi3} > (expr_list:REG_DEAD (reg:DI 31 [ _1 ]) > (nil))) insn 7 was optimized to the simple copy by ext-dce. That looks fine. Combine comes along and squashes them together resulting in: > (insn 8 7 10 2 (set (reg:DI 39 [ _2 ]) > (ashift:DI (subreg:DI (reg/v:SI 37 [ __major ]) 0) > (const_int 8 [0x8]))) "j.c":7:48 322 {*ashldi3} > (nil)) Which also looks good. After IRA's allocation, in the middle of reload we have: > (insn 8 7 10 2 (set (reg:DI 8 %a0 [orig:39 _2 ] [39]) > (ashift:DI (subreg:DI (reg/v:SI 0 %d0 [orig:37 __major ] [37]) 0) > (const_int 8 [0x8]))) "j.c":7:48 322 {*ashldi3} > (nil)) Again, sensible. The pattern requires op0 and op1 to match, so we try to figure out if d0 & a0 are the same underlying register. So we get into this code in operands_match_p: > if (code == SUBREG) > { > i = REGNO (SUBREG_REG (x)); > if (i >= FIRST_PSEUDO_REGISTER) > goto slow; > i += subreg_regno_offset (REGNO (SUBREG_REG (x)), > GET_MODE (SUBREG_REG (x)), > SUBREG_BYTE (x), > GET_MODE (x)); > } > else > i = REGNO (x); There's a similar fragment for the other operand. The key is that subreg_regno_offset call. That call assumes the subreg is representable. But in the case of (subreg:DI (reg:SI d0)) we're going to get -1 (remember, m68k is a big endian target). That -1 gets passed to hard_regno_regs via this code (again, just showing one of the two copies of this fragment): > if (REG_WORDS_BIG_ENDIAN > && is_a <scalar_int_mode> (GET_MODE (x), &xmode) > && GET_MODE_SIZE (xmode) > UNITS_PER_WORD > && i < FIRST_PSEUDO_REGISTER) > i += hard_regno_nregs (i, xmode) - 1; That triggers the reported ICE. It appears this has been broken since the conversion to SUBREG_BYTE way back in 2001, though possibly it could have been some minor changes around this code circa 2005 as well, it didn't seem worth putting under the debugger to be sure. Certainly the code from 2001 looks suspicious to me. Anyway, the fix here is pretty simple. The routine "simplify_subreg_regno" is meant to be used to determine if we can simplify the subreg expression and will explicitly return -1 if it can't be represented for one reason or another. It checks a variety of conditions that aren't worth listing here. Bootstrapped and regression tested on x86 (after reverting an unrelated patch from Richard S that's causing multiple unrelated failures), which of course doesn't really test the code as x86 is an LRA target. Also built & tested the crosses, none of which show issues (and some of which are reload targets). m68k will bootstrap & regression test tomorrow, but I don't think there's any point in waiting for that. Pushing to the trunk. PR rtl-optimization/116199 gcc/ * reload.cc (operands_match_p): Verify subreg is expressable before trying to simplify and match it to another operand. gcc/testsuite/ * gcc.dg/torture/pr116199.c: New test.
