[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le

["linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.