https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> --- On Sat, 31 Aug 2019, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323 > > Eric Botcazou <ebotcazou at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |ebotcazou at gcc dot gnu.org > > --- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > The test fails on SPARC too because it was aligned with the x86. We really > need to make a global decision about LTGT, otherwise we should keep the status > quo and revert the x86 change. But the status qou is broken as can be seen in this PR. We can of course fix conservatively on the folding side (basically think of LTGT as having "both" behaviors which I guess should make it simply unused, and thus we should simply remove LTGT_EXPR). 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. 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. 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".
