https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
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 #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #16)
> (In reply to Richard Biener from comment #14)
> > (In reply to Andrew Pinski from comment #13)
> > > (In reply to Andrew Pinski from comment #8)
> > > > ./a.ltrans6.ltrans.212t.forwprop4
> > > >
> > > > Removing dead stmt noDataCandVec$_M_start_888 = PHI <_1783(176),
> > > > _577(186)>
> > > > ...
> > > > Removing dead stmt:_598 = _888 + 16;
> > > >
> > > > So it looks like we remove the statement defining _888 and then
> > > > removing the
> > > > use.
> > > > The removal of _888 happens directly from forwprop while _598 definition
> > > > removal comes from simple_dce_from_worklist .
> > > >
> > > > The ICE happens because the ssa name _888 has already been freed so the
> > > > type
> > > > is null (and not in this case a pointer) since this was originally a
> > > > pointer
> > > > plus.
> > > >
> > > > Trying to reduce this further.
> > >
> > > _888 definition is from a BB which is going to be removed so we should not
> > > need to mark its uses as being needed for dce worklist. But I am not sure
> > > how to detect that case.
> >
> > forwprop shouldn't remove _888 if there's a use left. When adding
> > simple_dce_from_worklist, did you remove some manual stmt removal
> > (adding to to_remove)? Having both is a bit ugly (see also
> > remove_prop_source_from_use), but the sets need to be separate to
> > avoid interactions like this.
>
> Richard, you are the one who added simple_dce_from_worklist to forwprop in
> the end; I had tried originally by not do the manual one but ran into
> regressions so I didn't submit it.
Did I ... ah you only effectively amended it (r15-2981-g3ae8794665ee7c)
and fixed it (r15-2691-g33baa20c5cdcf5).
So I'll take this bug and will try to unsort the mess ...
