This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix middle-end/67133, part 1
- From: Marek Polacek <polacek at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 14 Aug 2015 22:46:49 +0200
- Subject: Re: [PATCH] Fix middle-end/67133, part 1
- Authentication-results: sourceware.org; auth=none
- References: <20150814112006 dot GR3335 at redhat dot com> <CAFiYyc2P_d=h=QHGjoDi0uONLFbe3gmKPvcDcABwOsvSBHuZyw at mail dot gmail dot com> <20150814132945 dot GS3335 at redhat dot com> <55CE002E dot 6000108 at redhat dot com> <20150814153224 dot GU3335 at redhat dot com> <55CE0A5A dot 4070802 at redhat dot com> <20150814195836 dot GB2093 at redhat dot com> <55CE5054 dot 5080400 at redhat dot com>
On Fri, Aug 14, 2015 at 02:32:20PM -0600, Jeff Law wrote:
> On 08/14/2015 01:58 PM, Marek Polacek wrote:
> >On Fri, Aug 14, 2015 at 09:33:46AM -0600, Jeff Law wrote:
> >>>Ok, I'll investigate and come back to y'all when/if I find something.
> >>Thanks. I still regret using the TREE_TYPE as a way to chain elements in
> >>the free list:( I didn't want to add another pointer field...
> >
> >It's actually plain to see what's happening. Before isolate-paths we've got
> >
> > <bb 2>:
> > ...
> > SR.5_10 = MEM[(const struct A &)0B];
> > ...
> > c_13 = C::size (&p1);
> > ...
> > if (_14 != 0)
> > goto <bb 3>;
> > else
> > goto <bb 4>;
> >
> > <bb 3>:
> > fn1 (&D.2434.OutBufCur, &b, c_13);
> >
> >Then in isolate-paths in find_explicit_erroneous_behaviour we're walking the
> >stmts in bb 2 and we find a null dereference, so insert_trap_and_remove_trailing_statements
> >comes in play and turns bb 2 into:
> >
> > <bb 2>:
> > ...
> > SR.5_10 = MEM[(const struct A &)0B];
> > __builtin_trap ();
> >
> >i.e. it removs the defining statement for c_13. Then find_explicit_erroneous_behaviour
> >walks over bb 3, hits the fn1 (&D.2434.OutBufCur, &b, c_13); statement, and
> >ICEs on the c_13 argument: it's a released SSA name with NULL TREE_TYPE.
> >
> >The question now is what to do with that. Skip SSA_NAME_IN_FREE_LIST? That
> >sounds weird. Note that we're going to remove bb 3 and bb 4 anyway...
> Jeez, looking at the code N years later, I feel like a complete idiot. Of
> course that's not going to work.
>
> We certainly don't want to peek at SSA_NAME_IN_FREE_LIST.
Yeh, I thought as much.
> I wonder if we should be walking in backwards dominator order to avoid these
> effects. Or maybe just ignoring any BB with no preds. I'll ponder those
> over the weekend.
I suppose both ought to work. Or at least theoretically we could run e.g.
cleanup_cfg to prune the IR after we've inserted trap and removed trailing
stmts so that it gets rid of unreachable bbs. Would that make sense?
Anyway, if you think of how would you like to solve this I can take a crack
at it next week.
Marek