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)?