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