From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28053 invoked by alias); 16 Dec 2011 12:50:20 -0000 Received: (qmail 28041 invoked by uid 22791); 16 Dec 2011 12:50:20 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Dec 2011 12:50:07 +0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/51573] [4.7 Regression] ICE (segfault) in lto_varpool_encoder_encode_initializer_p Date: Fri, 16 Dec 2011 13:12:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2011-12/txt/msg01796.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51573 --- Comment #7 from Richard Guenther 2011-12-16 12:50:05 UTC --- (In reply to comment #6) > It's a really messed up situation as with the C++ units > > void > bar1 (void) > { > extern void foo (int); > foo (0); > } > > --- > > void > bar2 (void) > { > extern void foo (int); > foo (0); > } > > --- > > void foo (int) {} > > we _do_ need to enter the function local foo's for decl/cgraph merging. > But OTOH we cannot, as the merged decl can only appear in one BLOCK_VARS > list. ISTM that either the frontends should move those over to > BLOCK_NONLOCALIZED_DECLS or all frontends consistently need to put a > decl copy in BLOCK_VARS for the sake of debuginfo (still using the > global-scope decl for the actual call) - that is what the C frontend > is doing and that works quite well. > > Jason? Can we please change the C++ frontend to mimic what the C > frontend does here? See c-decl.c:1199ff. > > I'm testing another (temporary?) workaround, still prone to the above > issue. And it exactly shows the issue during LTO bootstrap with `is_cpp_driver' referenced in section `.text' of /tmp/ccNdxpcJ.ltrans15.ltrans.o: defined in discarded section `.text' of gcc.o (symbol from plugin) collect2: error: ld returned 1 exit status make[3]: *** [cpp] Error 1 :(