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
