http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2014-05-05
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
You are talking about
_73 = __builtin_malloc (16);
...
_79 = _73;
...
_79->count = _81;
...
_83->count = _85;
...
_86 = _73;
_87 = _86->count;
note that FRE doesn't do copy-propagation at its simplification stage.
Usually the issue is that alias info isn't the best possible, and indeed:
# PT = nonlocal escaped
_2 = MEM[(const struct I &)c_3(D)].o;
...
# PT = nonlocal escaped { D.2585 }
_83 = _2;
...
# PT = { D.2585 }
_86 = _73;
_87 = _86->count;
so _86->count is possibly clobbered by the store because the pointer may
point to the malloc result.
So ... as FRE figures out some pointer equivalencies it could ideally
also take the stricter points-to info into account. It already somewhat
does this, but obviously not fully (see vn_reference_lookup_3, the
"First try to disambiguate ..." code at the beginning).
Hmm.
Confirmed (FRE is to blame).
I will have a look (at some point).
