https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> --- So I wonder about: --- gcc/config/i386/i386-expand.cc.jj 2023-01-04 10:45:49.978883731 +0100 +++ gcc/config/i386/i386-expand.cc 2023-01-05 18:22:40.228518935 +0100 @@ -3271,10 +3271,12 @@ ix86_expand_int_movcc (rtx operands[]) { negate_cc_compare_p = true; std::swap (ct, cf); - code = EQ; } else if (code == EQ && op1 == const0_rtx && cf == -1) - negate_cc_compare_p = true; + { + negate_cc_compare_p = true; + code = NE; + } } diff = ct - cf; @@ -3319,11 +3321,7 @@ ix86_expand_int_movcc (rtx operands[]) /* To simplify rest of code, restrict to the GEU case. */ if (compare_code == LTU) - { - std::swap (ct, cf); - compare_code = reverse_condition (compare_code); - code = reverse_condition (code); - } + std::swap (ct, cf); else { if (fpcmp) @@ -3333,6 +3331,10 @@ ix86_expand_int_movcc (rtx operands[]) else PUT_CODE (compare_op, reverse_condition (GET_CODE (compare_op))); + if (SCALAR_FLOAT_MODE_P (GET_MODE (op0))) + code = reverse_condition_maybe_unordered (code); + else + code = reverse_condition (code); } diff = ct - cf; but am not very sure about that, especially the floating point stuff, e.g. whether for -ffast-math it shouldn't actually be reverse_condition (and not add any REG_EQUAL note if code is UNKNOWN?).