https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61452
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- Setting value number of f.7_12 to f.7_21 (changed) Setting value number of g_18 to g_10 (changed) Setting value number of f.7_12 to e.1_6 (changed) Setting value number of g_18 to _13 (changed) Setting value number of f.7_12 to f.7_21 (changed) Setting value number of g_18 to g_10 (changed) Setting value number of f.7_12 to e.1_6 (changed) Setting value number of g_18 to _13 (changed) Setting value number of f.7_12 to f.7_21 (changed) Setting value number of g_18 to g_10 (changed) Setting value number of f.7_12 to e.1_6 (changed) Setting value number of g_18 to _13 (changed) Setting value number of f.7_12 to f.7_21 (changed) Setting value number of g_18 to g_10 (changed) Setting value number of f.7_12 to e.1_6 (changed) Setting value number of g_18 to _13 (changed) ... e.1_6 is a "better" leader for f.7_12. Ok, one reason is that even though we don't change the lattice value of the PHI g_1 = PHI <g_10, g_18> from g_1 (varying) to g_10 in the 7th (for example) iteration we _do_ adjust its ->expr and thus simplify expressions differently. That's of course a no-no, if the lattice value doesn't change it may really not change. The whole dance visit_phi does with trying to set ->expr and ->has_constants when it figured out a leader is pointless anyway - those are only relevant for VARYINGs (in which case they are bogus).
