https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
Kewen Lin <linkw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bergner at gcc dot gnu.org,
| |jsm28 at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org,
| |rsandifo at gcc dot gnu.org,
| |segher at gcc dot gnu.org
--- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
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?
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.
