https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97567
--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> --- The original fix was incorrect. It papered over a problem by reducing opportunities it could find. Given if (c_2 || c_3) If the FALSE edge is taken, this is ! (c_2 || c_3) which is equivalent to !c_2 && !c_3.. so performing the intersection as combine_logical was originally doing was correct. I found this by examining cases we were missing because this was no longer being combined properly. which sent be back to this PR to figure out what the real reason for the failure was. The GORI design specification calculates outgoing ranges using dependency chains, but as soon as the chain goes outside the current block, we are suppose to revert to using the on-entry range since control flow could dictate further range changes. I had noticed that on certain occasions we'd peek into other blocks, and each time I saw it, it was beneficial and seemed like a harmless recalculation, So I let it go. In this particular case, during the on-entry cache propagation we were peeking into another block to pick up a value used in the logical OR operation. Unfortunately, the on-entry cache hadn't finished propagating and the incomplete range was picked up from that other block instead of the current one, and we ended up calculating a [0,0] range on an outgoing edge that should have been VARYING. And bad things happened. The fix is to patch the logical evaluation code to do the same thing as the non-logical code, follow the spec, and simply use the range-on-entry value for the block if the def chain leads out of the current block
