https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71559
--- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to jos...@codesourcery.com from comment #11)
> There are definitely bugs on some architectures involving ordinary ordered
> comparisons such as < and >= wrongly using quiet instructions. See bug
> 52451 for i386 (x87 floating point) and bug 58684 for powerpc, for
> example. A consequence of this is that if you add tests of comparisons
> doing the right thing, some of those tests would immediately fail on some
> architectures.
PR 52451 involves x87 compares as well as SSE compares. The invalid (?) compare
mode for x86 target comes from config/i386.c:
--cut here--
/* Figure out whether to use ordered or unordered fp comparisons.
Return the appropriate mode to use. */
machine_mode
ix86_fp_compare_mode (enum rtx_code)
{
/* ??? In order to make all comparisons reversible, we do all comparisons
non-trapping when compiling for IEEE. Once gcc is able to distinguish
all forms trapping and nontrapping comparisons, we can make inequality
comparisons trapping again, since it results in better code when using
FCOM based compares. */
return TARGET_IEEE_FP ? CCFPUmode : CCFPmode;
}
--cut here--
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.
Referring to Jakub's observation in Comment #9: As mentioned b HJ, the wrong
mode is due to the above function (PR 37158).
> (These sorts of local bugs with particular operations or optimizations
> being incorrect regarding exceptions are certainly easier to fix than the
> issues with optimizations not being aware of exceptions and rounding modes
> as extra inputs / outputs to floating-point operations. The ones with
> individual operations could I expect largely be found through thorough
> test coverage; those with optimizations might be harder to find.)
>
> Note that there is some ambiguity about whether LTGT RTL (and
> corresponding GENERIC / GIMPLE) should be a quiet operation corresponding
> to islessgreater, or ((x < y) || (x > y)) raising exceptions for quiet
> NaNs. See the discussion at
> <https://gcc.gnu.org/ml/gcc-patches/2015-02/threads.html#00555>. Fixing
> the ambiguity in either direction would probably involve changes to the
> part of the compiler expecting the other semantics.
