From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6EB293858D38; Thu, 9 Nov 2023 07:57:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6EB293858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1699516628; bh=Ne/Asvpq7Flf3Y60BvviwyC2YFeVp6rpZRCHpb/GKro=; h=From:To:Subject:Date:In-Reply-To:References:From; b=X4uTBwF2aytrZLLRBhOciszbhxDSETRaxVt7cQBKlXf1GunCOLmjJm98xRqvzXjb4 rJYVagGoabPWnnTK3aZsxRWCPv/4ZPSGiuRWrlHMeyzRfYZp7Tu0g7oqFahOmjGL7q dKOGdEOBS2qWlggE538Y7dd+uY2aACG1AdQmk4LU= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/112449] Arithmetic operations can produce signaling NaNs Date: Thu, 09 Nov 2023 07:57:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 13.2.1 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: cc 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=3D112449 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsm28 at gcc dot gnu.org, | |rguenth at gcc dot gnu.org --- Comment #8 from Richard Biener --- I think if you can reproduce the issue with -fsignaling-nans (which default= s to off) then I would consider this to be an implementation issue. The GCC middle-end shouldn't clang to contradicting wording in the C standard here. In particular we say @opindex fsignaling-nans @item -fsignaling-nans Compile code assuming that IEEE signaling NaNs may generate user-visible traps during floating-point operations. Setting this option disables optimizations that may change the number of exceptions visible with signaling NaNs. This option implies @option{-ftrapping-math}. Changing tem =3D x * 1.0 to tem =3D x would possibly change the number of o= bserved traps if tem is used more than once. OTOH below we also say This option is experimental and does not currently guarantee to disable all GCC optimizations that affect signaling NaN behavior. so bugs in this area are expected (but they are still bugs IMHO). CCing Joseph for clarification. Note a quick check with double foo (double x) { return x * 1.0; } and -O2 -fsignaling-nans shows the multiplication is preserved (on x86_64), so is your example in godbolt where you fail to specify -fsignaling-nans. I agree the documentation is maybe not entirely clear about the effect.=