From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30285 invoked by alias); 8 Dec 2009 16:35:37 -0000 Received: (qmail 30233 invoked by alias); 8 Dec 2009 16:35:25 -0000 Date: Tue, 08 Dec 2009 16:35:00 -0000 Message-ID: <20091208163525.30232.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/42110] [4.5 Regression] ICE with inlining In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "hubicka at ucw dot cz" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-12/txt/msg00852.txt.bz2 ------- Comment #10 from hubicka at ucw dot cz 2009-12-08 16:35 ------- Subject: Re: [4.5 Regression] ICE with inlining > I assumed it is special vtable handling (that likely doesn't cause the > addressable flag to be set?) - I simply stopped debugging at the point > where I noticed the node gets removed even though there are still > indirect calls that possibly can reach it. The problem is uglier. When we clone node and we inline it, we must keep the clone around (since while inlining we can't apply the changes needed by ipa-cp clonning or other passes in general). But since this interfere with reachability as toon noticed, we put this node into "limbo stage" (i.e. it is around, has no call edges). When we decide to materialize it, we add the edges as previously indirect creating the extra call that should not exist. I've fixed it by simply removing those edges once clonning is finished. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42110