https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 2 Sep 2019, ebotcazou at gcc dot gnu.org wrote: > 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? Yes. > 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. Lets do it.
