From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0E774385CC8E; Mon, 2 Oct 2023 11:08:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0E774385CC8E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1696244894; bh=W6E47ydKQwnyBYBHVHC+dG14E3Xbw+7VhtjlRo9+Gc8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vzZI5EMi4Z7Z/ikJz7WTq1ZE8ZdUWX72INWnSPy5tu4vqFGknmVC4nFDsTngttuSW P+oeQkfqyLcGhzk0Ndif0/ExiaRDsfPdP3L2mg0XyBcB7EDOM09/D8672QnnI6e2r4 0im994RlD1MYqF9rZTnoEE/YUfAMixBi0ho50j+w= From: "amonakov at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2 Date: Mon, 02 Oct 2023 11:08:12 +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: 13.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: amonakov at gcc dot gnu.org X-Bugzilla-Status: NEW 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 everconfirmed short_desc resolution bug_status cf_reconfirmed_on 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=3D111655 Alexander Monakov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amonakov at gcc dot gnu.org Ever confirmed|0 |1 Summary|wrong code generated for |[11/12/13/14 Regression] |__builtin_signbit and 0./0. |wrong code generated for |on x86-64 -O2 |__builtin_signbit and 0./0. | |on x86-64 -O2 Resolution|DUPLICATE |--- Status|RESOLVED |NEW Last reconfirmed| |2023-10-02 --- Comment #9 from Alexander Monakov --- It's true that the sign of 0./0 is unpredictable, but we can fold it only w= hen the division is being eliminated by the folding.=20 It's fine to fold t =3D 0./0; s =3D __builtin_signbit(t); to s =3D 0 with t eliminated from IR, but it's not OK to fold t =3D 0./0 s =3D __builtin_signbit(t); to t =3D 0./0 s =3D 0 because the resulting program runs as if 0./0 was evaluated twice, first to= a positive NaN (which was used for signbit), then to a negative NaN (which fed the following computations). This is not allowed. This bug was incorrectly classified as a dup. The fix is either to not fold this, or fold only when we know that the division will be eliminated (e.g. = the only use was in the signbit). Reopening.=