From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 76B46385E83A; Wed, 3 Mar 2021 12:16:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 76B46385E83A From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/99101] optimization bug with -ffinite-loops Date: Wed, 03 Mar 2021 12:16:33 +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: 11.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth 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 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, 03 Mar 2021 12:16:33 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99101 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hubicka at gcc dot gnu.org --- Comment #21 from Richard Biener --- So I'm somewhat lost in pointing to the actual error. And I'm not sure the= re is any error, just unfortuate optimization behavior in the face of the test= case being undefined with -ffinite-loops (or in C++). That said, more "sensible" optimization from the undefined behavior would have been to exit the loop, not preserving the if (xx) test. With preservi= ng it we either end up with infinite puts() or no puts() calls both which have the "wrong" number of invocations of the side-effect in the loop. There's still the intuitively missing control dependence on the if (at_eof) check (which is also missing without -ffinite-loops but doesn't cause any wrong DCE there). But as said my gut feeling is that control dependence doesn't capture the number of invocations but only whether something is invoked. That's likely why we manually add control dependences of the latch of loops for possibly infinite loops. CCing Honza who added the control-dependence stuff and who may remember some extra details.=