https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #6)
> It's certainly an issue reported here, for one complete fix I did some more
> investigation how the option -ftrapping-math affects things, from what LLVM
> generates, it looks to me that:
> 1) with -ftrapping-math, we can assume fp operations can raise exceptions
> (user visible as doc said), here __builtin_isnan should not raise exception
> even for sNaN, so it uses vector int instructions instead.
> 2) while with -fno-trapping-math, we can assume fp operations can't raise
> exceptions, and as doc said "This option requires that -fno-signaling-nans
> be in effect", so there is no sNaN at all, safe to use vector fp
> instructions which don't trap for qNaN.
>
> It's concluded that __builtin_isnan is supposed not to trap even if the
> given value is sNaN.
>
> But with one simple scalar version of case with __builtin_isnan, I don't see
> GCC honor -ftrapping-math from the code generated on both Power and aarch64:
>
> ----
> #define _GNU_SOURCE
> #include "math.h"
>
> int func(double x)
> {
> return __builtin_isnan (x);
> }
> ----
>
> w/ -ftrapping-math or -fno-trapping-math, it gets the same insns like:
>
> aarch64:
> fcmp d0, d0
> cset w0, vs
> ret
>
> ppc64le:
> fcmpu 0,1,1
> mfcr 3,128
> rlwinm 3,3,4,1
>
> Both fcmpu and fcmp would trap for sNaN, is it expected with the current GCC
> implementation?
But the key is -fsignalling-nans (default off)
> Tested with compiler explorer, I saw LLVM generates insns without fcmpu on
> Power, like:
>
> mffprd 4, 1
> li 3, 2047
> rldic 3, 3, 52, 1
> clrldi 4, 4, 1
> subc 4, 3, 4
> subfe 3, 3, 3
> neg 3, 3
> blr
>
> though I did still see LLVM uses fcmp on aarch64 (maybe a warning saying
> "overriding currently unsupported use of floating point exceptions on this
> target" can explain it).
>
> Another question in mind is that I saw GCC lowed __builtin_isnan with tree
> code UNORDERED_EXPR, does it mean that UNORDERED_EXPR has the same semantic
> as what's concluded for __builtin_isnan above (that is not to trap for both
> qNaN and sNaN)? It seems internal documentation doesn't say much on this.
