From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29289 invoked by alias); 27 Aug 2011 17:36:26 -0000 Received: (qmail 29055 invoked by uid 22791); 27 Aug 2011 17:36:25 -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; Sat, 27 Aug 2011 17:36:10 +0000 From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs Date: Sat, 27 Aug 2011 18:16: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: hubicka at gcc dot gnu.org X-Bugzilla-Status: NEW 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: 2011-08/txt/msg02234.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #22 from Jan Hubicka 2011-08-27 17:35:27 UTC --- Carry, is there any chance to move ahead on this problem? I see you posted the PREVAILING_DEF_IRONLY_EXP but it was never committed. Concerning Rafael's comment: Why is PREVAILING_DEF_IRONLY_EXP needed? I think it can be solved with just PREVAILING_DEF if we say that the compiler can drop references to them if it knows they are provided in any DSO. The only case I can see where this would almost be a problem is something like This is not possible with current formulation of plugin API. It explicitely says "Any symbol marked PREVAILING_DEF must be defined in one object file added to the link after WPA is done, or an undefined symbol error will result" We could also go that route I guess, but 1) We will have to bump API version or something to indicate whether compiler is allowed to drop the symbols or not. With current binutils implementation bad things happens when compiler decided to drop the symbol it is not supposed to (my original implementation did so and it resulted in problems, especially in large dynamic linker tables) 2) the LTO produced COMDAT function will likely be better, so we will lose bit of code quality 3) There are cases where function is output COMDAT but it is keyed (i.e. with the repo files). In this case we will not be able to drop the symbol when it becomes unnecessary at LTO time because we will not know whether the symbol is used by non-LTO code or not. All those reasons are rather side cases and thus weak, but because we are effectively changing API anyway and because PREVAILING_DEF_IRONLY_EXP makes compiler a bit more informed in well defined way, I would go for it. Honza