https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117364
Bug ID: 117364
Summary: [12/13/14/15 Regression][coroutines] Use of <retval>
triggers an ICE on spare
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Target: sparc-sun-solaris2.11
This was identified with the test case attached to PR115905, but is not
otherwise related to that patch or indeed any recent coroutines patch.
Rainer identified:
r11-1613-g788b962aa00959
as the original change.
This is copied from PR115905 for the record:
Rainer's original report has the issue triggering in the tree checks (and my
debugging of that says that the alignment entry appears to have been GGC'd - it
has the characteristic 0xafafafaf pattern).
Eric has added the following which suggests that the problem is occurring much
later (in RTL) - so it's a bit unclear (perhaps because there's a GGC issue
along the way?):
The symptom on 64-bit SPARC is that MEM_ALIGN is applied to something that is
not a MEM, but a PARALLEL:
(parallel:DI [
(expr_list:REG_DEP_TRUE (reg:DI 114 [ <retval> ])
(const_int 0 [0]))
])
This comes from the Early SRA pass which turns:
D.8652.D.8175._M_fr_ptr = _11;
<retval> = D.8652;
into
SR.40_20 = _11;
MEM[(struct Handle *)&<retval>] = SR.40_20;
which is a store to something that is not addressable at the RTL level.
