Re: [PATCH] Fix PR34462, another bug with create_ssa_artifical_load_stmt

[Richard Guenther <rguenther at suse dot de>]

On Fri, 14 Dec 2007, Richard Guenther wrote:

> 
> This fixes another unexpected non-renamed VOPs bug in connection with
> PRE and create_ssa_artifical_load_stmt.
> 
> The problem is that the operand scanner is triggered on a fake store 
> inserted
> by PRE insert_fake_stores() as if a new stmt_ann is generated, the stmt is
> marked modified and bsi_insert_after() will update the stmts operands in 
> this
> case.
> 
> For some reason this figures new, unrenamed virtual operands:
> 
> # VUSE <SFT.2_69, SFT.3_70, SFT.4, SFT.5, SFT.6, SMT.15_71> { SFT.2 SFT.3 
> SFT.4
> SFT.5 SFT.6 SMT.15 }
> storetmp.19_3 = *dest_22
> 
> which triggers this ICE.

In case you wonder why this happens, the store we based this load on got
its VOPs based on the pointers SMT, where we prune its aliases based
on knowledge which SFTs have never been written to.  Now for the above
load, we happen to have a NMT for dest_22 at this time and so add those
(pruned from the SMT aliases) SFT during add_vars_for_offset processing,
because at that point we no longer know which SFTs are written to (and
so we cannot do the same pruning there).

This inconsistency may still get exposed somewhere.

FYI,
Richard.