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...
Marek
