Re: [PATCH] Fix middle-end/67133, part 1

[Marek Polacek <polacek@redhat.com>]

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