From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 4D4F63858C98; Wed, 28 Feb 2024 12:35:01 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4D4F63858C98
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1709123701;
	bh=Ias970JTpJt5Ib5zqnYpnjd4bAQWUf4GMTcUKesZx8k=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ATpfVUVCzE9OgaMJZVVHO60RCo6IZQL3Cqcl0LngYbfCuBbq8ziVn5s7pnwPEHoI8
	 8nWZiMwm9sPS6rM/p11Gb8c+sMQxuGSTVw/gSOwFVBpEEN0r2RM8f3ffn7whvnQfcA
	 IILES87O8oQHc44ODBFpx6vY6SAbghDbXwcXZxME=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libquadmath/114140] different results for std::fmin/std::fmax
 and quadmath fminq/fmaxq if one argument=signaling_NaN
Date: Wed, 28 Feb 2024 12:35:00 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libquadmath
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: documentation
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114140-4-gFsX10qmsi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114140-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114140-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114140

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #16)
> (In reply to Richard Biener from comment #15)
> > It's the old argument on whether isnan(NaN) should return true or false=
 with
> > -ffinite-math-only.  With what we currently do "constant folding" sNaN =
into
> > NaN would be correct with -fno-signalling-nans, likewise constant foldi=
ng
> > Inf into 42.0 is "correct" for -ffinite-math-only.
> >=20
> > You are basically invoking undefined beavior when introducing sNaN into=
 a
> > program without using -fsignalling-nans.
>=20
> Then we should make it more clear in invoke.texi.  Currently the doc is
> implying the worst consequence using sNaN with -fno-signalling-nans is
> "changing the number of raised exceptions."

Yeah, the options that are not enabled by default (-fno-signalling-nans,
-fno-trapping-math) could see improvement here.

Usually -fno-X enables optimizations that would be invalid when X happens/is
present.  But that is nothing else than giving a free ticked to undefined
behavior, maybe "constrained undefined behavior", but I'm not 100% sure we'd
live up to that.

Aka isnan (NaN) is optimized to false with -ffinite-math-only, something
that's not valid when non-finite numbers are present.  Whether doing
so for literal NaN is "nice" remains questionable, but it's at least
consistent with the behavior of x =3D NaN; isnan (x);

So similarly -fno-signaling-nans enables optimizations that are not
valid when sNaNs are present.  Indeed "optimizations that may change the nu=
mber
of exceptions visible with signaling NaNs" is over-promising even if
effectively this is all that happens.=