[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins

["ubizjak at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Segher Boessenkool from comment #10)
> So should combine use targetm.cc_modes_compatible here?

Yes. The trappines of FP compares is distinguished by their mode, so
I guess something along the following patch should work:

--cut here--
diff --git a/gcc/combine.c b/gcc/combine.c
index d71e50fdefb5..0220be2e484e 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -6787,6 +6787,14 @@ simplify_set (rtx x)
       else
        compare_mode = SELECT_CC_MODE (new_code, op0, op1);

+      /* Do not change compare mode of a floating point compare to
+        an incompatible mode.  Targets distingush trapping and
+        non-traping compares by their compare mode, and SELECT_CC_MODE
+        could return different mode for a new_code.  */
+      if (FLOAT_MODE_P (GET_MODE (op0))
+         && !targetm.cc_modes_compatible (compare_mode, GET_MODE (dest)))
+       compare_mode = GET_MODE (dest);
+
       /* If the mode changed, we have to change SET_DEST, the mode in the
         compare, and the mode in the place SET_DEST is used.  If SET_DEST is
         a hard register, just build new versions with the proper mode.  If it
--cut here--