https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71559
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #12)
> The "Once gcc is able ..." part in the comment implies that simply returning
> different mode based on the incoming rtx code argument won't work. OTOH,
> this is ancient comment, so things *could* work now.
E.g. fold-const.c (invert_tree_comparison) now has:
if (honor_nans && flag_trapping_math && code != EQ_EXPR && code != NE_EXPR
&& code != ORDERED_EXPR && code != UNORDERED_EXPR)
return ERROR_MARK;
so at least for -ftrapping-math and no -ffast-math suboptions it should do the
right thing, but we had this for years (e.g. 4.4 gave up always, instead of
properly being able to invert EQ/NE/ORDERED/UNORDERED.
So, shall the backend emit different code for -ftrapping-math vs.
-fno-trapping-math, perhaps by using the non-trapping insns for the latter for
all comparisons (both scalar and vector)?
