From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25535 invoked by alias); 2 Feb 2015 06:31:23 -0000 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 Received: (qmail 25461 invoked by uid 48); 2 Feb 2015 06:31:18 -0000 From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works) Date: Mon, 02 Feb 2015 06:31: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-Version: 5.0 X-Bugzilla-Keywords: lto, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-02/txt/msg00084.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 --- Comment #3 from Jan Hubicka --- Hmm, interesting, I did not even think we support this ;) I am not sure how much it makes sense to do incremntal linking like this with LTO because this limits LTO to incremental link only (it would perhaps make sense to produce LTO file after merigng in this case). What changed since GCC 4.9 is that visibility pass is now more aggressive on bringing comdat locals. In resolution file we have: $ more *.res 1 file2.o 6 212 f6705eca5fa850e3 PREVAILING_DEF _ZN11CDialogBase11GetDocumentEv 217 f6705eca5fa850e3 PREVAILING_DEF dialog2 204 f6705eca5fa850e3 PREVAILING_DEF _ZTV11CDialogBase 232 f6705eca5fa850e3 PREVAILING_DEF _ZTS11CDialogBase 248 f6705eca5fa850e3 PREVAILING_DEF _ZTI11CDialogBase 259 f6705eca5fa850e3 UNDEF _ZTVN10__cxxabiv117__class_type_infoE which makes us to believe that all the symbols are previaling ones for current DSO. The trick it that incrementally this is not quite true. I suppose only way to make this work reliably is to modify: static bool resolution_to_local_definition_p (enum ld_plugin_symbol_resolution resolution) { return (resolution == LDPR_PREVAILING_DEF || resolution == LDPR_PREVAILING_DEF_IRONLY_EXP || resolution == LDPR_PREVAILING_DEF_IRONLY); } to exclude LDPR_PREVAILING_DEF and similarly in ipa.c. This way we lose some optimization in non-incremental linking where we know that we are the only LTO unit in proram. So perhaps doing this conditionally on -r? We will probably makes it funnier to produce testcases. Or we don't really care as it normally affects only cases where non-LTO and LTO objects are mixed.