Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549

[Richard Guenther <richard.guenther@gmail.com>]

On Mon, Apr 26, 2010 at 4:25 AM, Dave Korn
<dave.korn.cygwin@googlemail.com> wrote:
> On 25/04/2010 23:16, Steven Bosscher wrote:
>> On Mon, Apr 26, 2010 at 12:27 AM, Dave Korn wrote:
>>
>>>  Is there a PR open about this, or any notes anywhere?  Being as I use a
>>> non-ELF platform and so gold is not an option, I'd be pleased to help with
>>> making this work.
>>
>> See http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00015.html for some
>> first steps.
>>
>> I don't understand this, actually. When I look at lto-elf/lto-coff,
>> there seems to be AR support already. But this doesn't work,
>> apparently?
>
>  There is support for offsetting an arbitrary way into a file before
> beginning reading, which in theory would let us read an archive member given
> some parsing of the archive header, but I think that we still lack any means
> of reading and parsing the archive, knowing what's there, and selecting the
> member we want.  So, we have support for reading a single archive member as an
> object for LTOing, but we need guidance about which ones and where from.
>
>  If I understand correctly, what we farm out to gold/lto-plugin is the task
> of identifying a) which archive members are required to be pulled into the
> final link depending on the undefined references found in the existing object
> files and b) what offsets those members begin at.
>
>  On the other hand, I may not understand correctly.

That's correct.  Now I delayed hacking this all into collect2
(because I don't think that's the correct place to do it).  I first
wanted to cleanup the driver <-> lto1 interface so we do _not_
rely on collect2 to identify LTO objects but instead have lto1
do that work and communicate final link objects to the driver
back via a response file (same for -fwhopr WPA / LTRANS
stage - do not exec lto1 from lto1 but rather tell the driver
the set of LTRANS files).

That's also the only easy way to get rid of the .comm __gnu_lto_v2
marker and simply check the availability of one of the always
present LTO sections.  For ar archieves it is easy to iterate
through them and we need to re-write them anyway if we want
to support partly LTO / non-LTO objects inside an archive.

Now of course if ar support ends up to look easy and sane in
the collect2 framework then we can choose to not wait for
somebody doing the above suggested cleanups ...

Richard.

>    cheers,
>      DaveK
>
>