https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860
--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
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.
