https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100781
--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> --- So the new code base provides a more complete/consistent export list, and makes use of imports now. An import is the incoming value which can change an outgoing value. In this particular case we see: <bb 3> : _2 = (long int) f$b_17; _3 = _2 <= e_12(D); h_13 = (int) _3; i_14 = (int) d_10(D); _5 = h_13 >= i_14; n_15 = (int) _5; if (h_13 < i_14) goto <bb 4>; [INV] else goto <bb 5>; [INV] <bb 4> : // predicted unlikely by goto predictor. // predicted unlikely by goto predictor. if (d_10(D) != 0) goto <bb 6>; [INV] else goto <bb 7>; [INV] We look at more of these names than we use to, and f$b_17 is now taken into account. bb3 has a back edge from bb9, so we do a little back edge tracking earlier than we use to. Long story short: During the initial traversal, none of the other names in the block have yet been fully fleshed out when we arrive back at bb3 from the bottom, so the propagation engine uses global values as an initial value. In particular, we use h_13 which has none, so defaults to VARYING. And in "if h_13 < i_14", that gives us nothing for d_10. however, we later process h_13 = (int)_3, and discover it is actually [0,1] since _3 is a boolean. We propagate this new [0,1] value, but since it isnt in the dependency chain for d_10, we never re-evaluate d_10. Previously, the first time we evaluate d_10 we see that the edge 3->4 requires [0,1] < i_14 to be true, which means i_14 = [1, +INF] which also means that d_10 is non-zero and we fold the condition. The next round of GORI code I'm about to check in makes it fair straightforward to grab an initial value for h_13 even if it hasn't been fully evaluated yet.. so instead of VARYING, we'll get the [0,1] range for h_13, and everything will return to the way it was. There is more update/propagation/ordering stuff to come, but I suspect the forthcoming changes will resolve most of these sorts of issues.
