https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121493
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2025-08-11
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. So what happens is that we do not handle inserting fake refs that
are missing here. For the first aggregate copy we thus run into
/* When the LHS is already at the outermost level simply
adjust for any offset difference. Further lookups
will fail when there's too gross of a type compatibility
issue. */
if (!found && j == 0)
{
extra_off = vr->operands[i].off - lhs_ops[j].off;
i--, j--;
but there's now a "gross type compatibility issue", we have
tt.t and tt.t with once a FIELD_DECL for struct s1 and once for int.
So when visiting the earlier aggregate copy tt.t = t but with the
lookup RHS of tt.t (with the int field) we go past the MEM_REFs which
match up exactly but then we fail to process further (we don't allow
for even more gross type compatibility issues).
One could argue that for components we can handle by offset we should
simply go ahead, hoping for the best. That helps in this case.
I will test this.
