https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Other than that my view is that the GENERIC/GIMPLE side is correct.
> Besides even RTL "high-level" get's this consistent (may_trap_p_1),
> likewise simplify-rtx if my quick survey is correct.
Yes, the RTL middle-end indeed says that LTGT signals on NaNs.
> So IMHO siding with the non-target interpretation feels quite
> natural to me. rtl.texi has no entry for LTGT and both tree.def
> and rtl.def agree.
IMO that's less clear for rtl.def:
/* This is an ordered NE, ie !UNEQ, ie false for NaN. */
Do you read "ordered" as "signaling on NaNs"? Then what about EQ?
And even less clear for tree.def:
/* This is the reverse of uneq_expr. */
> The only disagreeing part is LTGT_EXPR in generic.texi which is "fuzzy" (says
> unordered but then "With the possible exception of @code{LTGT_EXPR}, all of
> these operations are guaranteed not to generate a floating point exception."
> So even that can be read as "agreement".
IMO it's just aligned with rtl.def/tree.def, i.e. it doesn't really take side.
So we need to modify rtl.def, tree.def and generic.texi to clearly state that
LTGT signals on NaNs, like GE/GT/LE/LT. And actually fix generic.texi because
LTGT_EXPR is *not* an unordered comparison operator: as rtl.def says, it's the
ordered NE, i.e. it returns false for NaNs.
