From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3C0FB3895FF8; Wed, 9 Nov 2022 08:48:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3C0FB3895FF8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1667983700; bh=25mzQybFN56a6n90osHaVNsQeM90UEv9zIWYzkZxJFM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AHsn1wSsfDUrgf0r1biaRmxcBHZRPuq4ezGsvVX9a1TC39czxAbvTwxHjsHVlxcxb hXbBlnNAbiADN2yRKwVWA/ymRk9/Q6Q2ILzepsjURC4ipO591Auj0cIaFcBG298svA vTOZdzJKlroJ2mvf1YDBvAEwfXmb4SyMgQZsMwZ4= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le Date: Wed, 09 Nov 2022 08:48:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 11.2.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: linkw at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105480 --- Comment #7 from Richard Biener --- (In reply to Kewen Lin from comment #6) > It's certainly an issue reported here, for one complete fix I did some mo= re > investigation how the option -ftrapping-math affects things, from what LL= VM > generates, it looks to me that: > 1) with -ftrapping-math, we can assume fp operations can raise exceptio= ns > (user visible as doc said), here __builtin_isnan should not raise excepti= on > even for sNaN, so it uses vector int instructions instead. > 2) while with -fno-trapping-math, we can assume fp operations can't rai= se > 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. >=20 > It's concluded that __builtin_isnan is supposed not to trap even if the > given value is sNaN. >=20 > 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 aarch= 64: >=20 > ---- > #define _GNU_SOURCE > #include "math.h" >=20 > int func(double x) > { > return __builtin_isnan (x); > } > ---- >=20 > w/ -ftrapping-math or -fno-trapping-math, it gets the same insns like: >=20 > aarch64: > fcmp d0, d0 > cset w0, vs > ret >=20 > ppc64le: > fcmpu 0,1,1 > mfcr 3,128 > rlwinm 3,3,4,1 >=20 > 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: >=20 > 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 >=20 > 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). >=20 > 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 semant= ic > as what's concluded for __builtin_isnan above (that is not to trap for b= oth > qNaN and sNaN)? It seems internal documentation doesn't say much on this.=