https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
And what in the end disambiguates this in LIM is aliasing_component_refs_p.
Note that LIM feeds it canonicalized __MEM <struct Target> ((struct Target
*)_26).D_43475.next, it instead uses MEM[(struct Base * *)_26 + 8B].
I think it goes wrong because LIM canonicalizes _26->...next which is a
ref at offset 8 to MEM[_26 + 8] _at offset 8_, the base is actually
recorded as MEM[_26] but get_ref_base_and_extent wouldn't get 8 out of
MEM[_26 + 8] and aliasing_matching_component_refs_p re-does that to adjust
the offset which in the end leads to some inconsistency.
What LIM tries to do is find a canonical representation for the ref which
is MEM[_26 + 8B], it also tries to preserve the base which is MEM[_26],
but that's somewhat in conflict here. It works for LIMs purposes but as
can be seen it doesn't work here.
The bad thing is that there isn't a consistent representation for this,
but also aliasing_matching_component_refs_p relying on this is bad?
