LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

Richard Guenther
Thu Apr 29 15:24:00 GMT 2010

2010/4/29 Jan Hubicka <>:
>> Well, we'd then need to re-architect the symbol merging and
>> LTO unit read-in to properly honor linking semantics (drop
>> a LTO unit from an archive if it doesn't resolve any unresolved
>> symbols).  I don't know how easy that will be, but it shouldn't
>> be impossible at least.
> We also should keep in mind that we really ought to be able to produce LTO .o files
> without actual assembly in, so either we should not tie this too much with linking
> process anyway or we need to output fake symbols into the LTO .o file when assembly
> is not done.
> (I guess one can just output empty variables and functions, but then .o will link
> without LTO and lead to wrong code).
> This is IMO quite important feature, we don't want to double compile times forever.

Well, what we should do anyway is short-cut compilation after
LTO bytecode output and go directly to expansion.  Otherwise
we risk to have different sets of symbols with the intermediate
object files and thus symbol resultion with GOLD does not
work compeltely (there are bugs about this already).

So compile-time wouldn't be _that_ bad (just RTL opts and


> Honza
>> >  I'm sketching a plan where collect2 invokes 'ld' as if to do an ordinary
>> > non-LTO link, but passes it a flag like "--lto-assist" which causes it to
>> > output a list of just the archive members that it actually needs to complete
>> > the link, in response file "filename.a@offset" format.  ISTM that this is the
>> > simplest method to avoid recompiling entire archives (sort of building a
>> > linker into the compiler!), and I guess I should also make it check for an LTO
>> > marker (whether symbol or section) and only output those members that actually
>> > contain any LTO data.
>> Yes - that would be basically a linker plugin without plugin support.
>> And I'd go even further and have LD provide a complete symbol
>> resolution set like we get from the gold linker-plugin.
>> That wouldn't help for old or non-gnu LDs of course.
>> >  Making lto1 understand archives seems logical at first, but I don't think
>> > it's much use without knowing which archive members we want in advance, and in
>> > that case the existing code that reads a single archive member by pretending
>> > it's an ordinary object file with a constant offset from the start of file
>> > marker already does all we need, or so it seems to me.
>> I think we should try without lto1 understanding archives first
>> (or we are basically re-implementing a linker in lto1).
>> Richard.
>> >    cheers,
>> >      DaveK
>> >
>> >

More information about the Gcc mailing list