http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47365
--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-20 12:01:23 UTC --- What happens is that when translating D.2739_9 = b.a[0].i; from bb6 to bb3 value-numbering does look through the aggregate copy b.a[0] = b.a[1]; continuing to look for b.a[1].i and finding D.2737_7 = b.a[1].i; from bb4 (which is ok - the consumer has to check availability). Thus b.a[1].i ends up in antic-out (not a problem) with a new value-number, it doesn't end up in antic-in of bb3. b.a[0].i is partially redundant in bb6, D.2739_4 is correctly found as the available expression for it via bb6. But when we translate b.a[0].i to bb3 again during insertion we again obtain b.a[1].i (because it's also still in the phi-translation cache). It is obviously not available here so we insert it. Oops. We don't prune invalid translations during insertion - that's the basic problem. We'd expect to find a leader as the translated expression has a SCCVN value-number. The problem is latent on trunk.
