From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 46592394DAE8; Wed, 24 Feb 2021 15:09:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 46592394DAE8 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, 24 Feb 2021 15:09: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: 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, 24 Feb 2021 15:09:34 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99101 --- Comment #12 from Richard Biener --- So we can massage post-dom compute to make control dependence which is defi= ned in terms of pdom do what we want. We have void dom_info::calc_dfs_tree () { ... /* In the post-dom case we may have nodes without a path to EXIT_BLOC= K. They are reverse-unreachable. In the dom-case we disallow such nodes, but in post-dom we have to deal with them. There are two situations in which this occurs. First, noreturn functions. Second, infinite loops. In the first case we need to pretend that there is an edge to the exit block. In the second case, we wind up with a forest. We need to process all noreturn blocks before we know if we've got any infinite loops. */ which then first visits blocks w/o successors, breaking our expectations. So with that in mind indeed connecting infinite loops to exit would circumvent the issue, but connect_infinite_loops_to_exit does not reliably avoid making the edge from the noreturn block (if that came first), dfs_find_deadend also likes noreturn blocks very much. Heuristically one could use loop info, but that fails to work for irreducib= le regions. One could also use marked backedges from a forward DFS walk (blocks with just backedges outgoing).=