From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F2E813858402; Wed, 27 Oct 2021 17:16:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F2E813858402 From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/84407] incorrect constant propagation with -frounding-math Date: Wed, 27 Oct 2021 17:16:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 7.3.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: joseph at codesourcery dot com 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: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 17:16:35 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D84407 --- Comment #5 from joseph at codesourcery dot com --- On Wed, 27 Oct 2021, rguenth at gcc dot gnu.org via Gcc-bugs wrote: > Also a question is the behavior on overflow when converting a real to an > integer (IIRC the behavior here is undefined, but we constant fold to the > largest/smallest integer here). We follow Annex F here (so unspecified value rather than undefined - as=20 discussed in other bugs, any given execution of the conversion in the=20 abstract machine needs to act as if it does return some value of the=20 type). > For integer to float conversions is the overflow considered before or aft= er > applying the rounding? That is, are there integer values that invoke > undefined behavior when converted to a real dependent on the rounding mod= e? It's fully defined regardless of the value (the appropriately rounded=20 result is returned, which might be an infinity in case of overflow, or the= =20 largest finite value depending on the rounding mode). Whether the conversion overflows can indeed depend on the rounding mode=20 (overflow occurs when a conversion in that rounding mode, with infinite=20 exponent range, would produce a result with an exponent too large to=20 represent in the floating-point format). For the IEEE formats and integer= =20 types supported by GCC, the only cases where overflow is possible are for=20 conversions to _Float16, and from unsigned __int128 to float.=