[Bug tree-optimization/47265] [4.6 Regression] Error: SSA name in freelist but still referenced

["matz at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265

Michael Matz <matz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #2 from Michael Matz <matz at gcc dot gnu.org> 2011-01-12 17:20:00 UTC ---
The underlying problem is that tree-ssa-forwprop.c recursively calls itself
on the same statement, updating it in the process.  That destroys the 
imm_use iterator for the outer iteration, making us miss on imm-use.
The definition then is removed (under the assumption that all imm-uses
are changed), leaving a stale reference to an SSA name in the free list.

In detail here's what happens, the situation at first:

  src_2 = &s_1(D)->b;
  src_20 = src_2 + 1;
  src_19 = [cond_expr] iftmp.0_11 != 0 ? src_20 : src_2;

forward_propagate_addr_expr (src_2) iterates over the imm-uses of src_2.
(1)
The first is the def of src_20, which itself is a pointer addition.
forward_propagate_addr_expr_1 happily tries to look through that one
calling forward_propagate_addr_expr recursively on src_20.  The imm-use
list of src_20 also contains statement src_19, which is now updated via
update_stmt.  Unfortunately that will clobber the iterator at (1)
to not contain the src_19 statement anymore.  So when returning the
outer loop on imm-uses(src_2) will now exit as if all imm-uses were
handled.

Caller will remove def(src_2), leaving us with:

  src_20 = &MEM[(void *)s_1(D) + 4B];
  src_19 = [cond_expr] iftmp.0_11 != 0 ? src_20 : src_2;

Boom.  Triggered by my patch perhaps, but latent problem.

The underlying problem is statements that can be reached over multiple
distinct paths of def-use chains.

I'll experiment with totally removing the recursion, it possibly isn't
necessary anymore since MEMREF because looking through type-casts and
the like isn't necessary.  And of course as this one shows it's simply
not correct to recurse on forward_propagate_addr_expr, at least as long
as the destination statement has more than one operand