[Bug tree-optimization/97567] [11 Regression] wrong code at -Os and above on x86_64-pc-linux-gnu

["amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

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