From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24034 invoked by alias); 4 Jun 2012 19:53:26 -0000 Received: (qmail 24023 invoked by uid 22791); 4 Jun 2012 19:53:24 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED 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; Mon, 04 Jun 2012 19:53:11 +0000 From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/53572] Some public symbols don't get to serialized LTO Date: Mon, 04 Jun 2012 19:53: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: lto X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at ucw dot cz X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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: 2012-06/txt/msg00205.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572 --- Comment #5 from Jan Hubicka 2012-06-04 19:52:51 UTC --- > > !node->symbol.used_from_other_partition > > - && (DECL_COMDAT (node->symbol.decl) > > + && ((DECL_COMDAT (node->symbol.decl) > > + && symtab_used_from_object_file_p ((symtab_node) node)) > > && !symtab_used_from_object_file_p Ah, yes. Sorry. > > I suppose. I would have expected used_from_other_partition to be true Well, used_from_other_partition reffers to IR partitions, not "other uses". I would not mix them unless we need so. There are some differences - like symbols from other partitions can be local and can use custom calling conventions. Symbols used form asm can't. > > But perhaps it is now resonable to expect V2 linker API even for GCC 4.7 based > > setups for sane LTO with C++? We already mention in release notes that V1 API > > is bad idea... > > Well, sure - assuming that we have a V2 capable linker is ok I guess. In the > end we should simply annotate the resolution file with the linker capability, > thus extend the file-format to include a one-line header with a version. As I tried to explain on IRC, this won't help since V1/V2 API differs already on compile time when we don't have linker plugin and have no clue what version of API will be used at linktime. It is possible to teach lto-plugin to do the hack instead of doing it in lto-streamer-out.c if we really want sane support for V1 API. Concerning the problem in this PR, i guess we probably should give up handling this sanely in V1 API: we already hide COMDAT vtables and type descriptions should be harmless/dropped by the linker eventually. Honza