------- Comment #2 from steven at gcc dot gnu dot org 2005-12-03 14:37 ------- Actually VRP doesn't catch it.
Do: - if (e[i] == 16) + if (e[i] == 16) so that store-CCP doesn't load e[0] anymore to find that it is 16. With that, the .vrp dump at -O2 looks like this: baz (r) { long unsigned int i; int D.1638; long unsigned int i.0; <bb 0>: goto <bb 3> (<L2>); <L0>:; i_4 = i_1; D.1638_6 = e[i_1]; if (D.1638_6 == 17) goto <L3>; else goto <L1>; <L1>:; i_7 = i_1 + 1; # i_1 = PHI <0(0), i_7(2)>; <L2>:; if (i_1 <= 3) goto <L0>; else goto <L3>; <L3>:; if (i_1 == 4) goto <L4>; else goto <L5>; <L4>:; foo (r_3); <L5>:; return; } The tree loop optimizers turn "(i_1 <= 3)" into "(i_1 != 4)", but there are no passes after VRP that use the ASSERT_EXPRs to propagate "i_1 == 4" down along the false-edge going to the block starting with label L3. So even at -O2 we don't catch this jump threading opportunity at the tree level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25243