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.
