https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122830
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Last reconfirmed| |2025-11-25
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
We have
<bb 2> :
D144916.c = fill_2(D);
D135323.l = D144916;
_1 = MEM[(const int *)&D135323];
if (_1 != fill_2(D))
and we 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--;
found = true;
}
but j == 1. We don't really handle this case in the already complicated
logic to match up references. The fix is likely to improve the snippet
above, also making it more robust at the same time.
Note the ultimate goal of this code is for
D135323.l = D144916;
to re-construct D144916.c which in itself looks impossible. So we'd
have to rely on a completely different way of forwarding the lookup,
purely based on offsets (which is what the above snipped does).
