From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D298C38708D0; Fri, 22 May 2020 09:55:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D298C38708D0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1590141346; bh=gNTrt/TVBwncUBa9I/8ia6K1OxJKeB8Kz3n2SIVCuF4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lLob9cTEB3iFkHOMU5Djys99WgU7Um6FVxycSkpTX6E0GIgEcZPZPnq7k0g2xPpjF AIKHzihiFME0lvuT2Bm+rF7mXycwxkvwQCaLJRv7iqWREm4H0btfFOsugpUji8zGv7 a4w+Ivn7Xhj4ujPC2ntiHod92ihcV2fakOPfc9ZE= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/95264] Infinite Loop When Compiling Templated C++ code at -O1 and above Date: Fri, 22 May 2020 09:55:46 +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: 10.1.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: WAITING 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: keywords 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: Fri, 22 May 2020 09:55:46 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95264 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |missed-optimization --- Comment #4 from Richard Biener --- clang documentation mentions they support [[gnu::flatten]], whether implementations match here is of course another question. I guess for a convoluted cgraph our flatten implementation leaves sth to be desired - if there's two calls to the same function we inline it fully twice and have to reap benefits of inlining all calls (recursively) in them twice rather than producing an optimized body for the flatten inlining first. One could envision some early cloning for the purpose of flattening, pushing down the flattening attribute to the clones that end up being inlined multiple times. Not sure how easy that would be - Honza?=