[Bug target/91323] LTGT rtx produces UCOMISS instead of COMISS

[ebotcazou at gcc dot gnu.org]

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.