https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100112
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
This circles around redundant store elimination which is tricky with TBAA since
even a "value-redundant store" can change the dynamic type and thus we need to
preserve it. See also PR101641 for a pending wrong-code issue here.
I _think_ we have an almost exact duplicate but let me take it, this is
related to last_vuse - we're doing the lookup w/ VN_NOWALK and thus don't
see the hashtable entry with the "optimized" VUSE from last_vuse handling.
IIRC VN_NOWALK is mainly a compile-time optimization, at elimination time
we even use VN_WALKREWRITE. It originally changed with
g:649caaad399d6f4865a4d0015a1ac76c3cce7eb0 as a wrong-code fix though.
