[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures

[amacleod at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #27 from Andrew Macleod <amacleod at redhat dot com> ---
Fixed with the simple approach in the email thread.

This boils down to a single place where we are trying to do things with
relations in ranger that are simply not safe when we need to honor NANs.

I think we can avoid all the other shuffling of relations, and simply not
perform this optimization when it comes to floats.

The case the routine handles is:

c_2 = a_6 > b_7
c_3 = a_6 < b_7
c_4 = c_2 && c_3

c_2 and c_3 can never be true at the same time, Therefore c_4 can always
resolve to false based purely on the relations.


Range-ops is unable to do this optimization directly as it requires examining
things from outside the statement, and is not easily communicated a simple
relation to operator_logical_and.

This routine proceeds to look at the definitions of c_2 and c_3, tries to
determine if there are common operands, and queries for any relations between
them.   If it turns out there is something, depending on whether its && or || ,
we use intersection or union to determine if the result of the logical
operation can be folded.  If HONOR_NANS is true for the float type, then we
cannot do this optimization, and bail early.