https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389
Georg-Johann Lay <gjl at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC| |law at gcc dot gnu.org Last reconfirmed| |2024-08-17 Summary|ICE in |[avr][15 regression] ICE in |extract_constrain_insn for |extract_constrain_insn for |avrtiny and -O2 |avrtiny and -O2 Keywords| |ra Blocks| |56183 Component|target |rtl-optimization --- Comment #1 from Georg-Johann Lay <gjl at gcc dot gnu.org> --- There is this insn from ext-dce (from -fdump-rtl-ira-details): (insn 180 179 181 26 (set (reg/v:SI 70 [ __paddec ]) (subreg:SI (reg/v:HI 78 [ __len ]) 0)) "/ssd1/build/avr/gcc-bug/avr/avrtiny/libstdc++-v3/include/bits/locale_facets_nonio.tcc":477:14 119 {*movsi_split} (nil)) Register allocation then assigns R30:HI to pseudo 78, but due to the paradoxical subreg, this becomes R30:SI which is not a valid hard register because R31 is the last valid general-purpose register. The reload dump (from -fdump-rtl-reload-details): (insn 180 900 181 27 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28) (const_int 28 [0x1c])) [91 %sfp+28 S4 A8]) (reg:SI 30 r30)) "/ssd1/build/avr/gcc-bug/avr/avrtiny/libstdc++-v3/inclu This insn is not valid because R30:SI is not a valid hard reg, so it's no wonder no valid insn constraint alternative is found and hence ICE. So the question is whether that paradoxical subreg from ext-dce is valid in the first place? Or is it a register allocation issue? As an aside, -mlra also ICEs because the code is too complicated for LRA (doesn't find reloads. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183 [Bug 56183] [meta-bug][avr] Problems with register allocation