On Thu, May 20, 2021 at 3:16 PM Richard Biener
<richard.guent...@gmail.com> wrote:
>
> On Thu, May 20, 2021 at 3:06 PM Martin Liška <mli...@suse.cz> wrote:
> >
> > On 5/20/21 2:54 PM, Richard Biener wrote:
> > > So why did you go from applying this per-file to multiple files?
> >
> > When I did per-file for {gimple,generic}-match.c I hit the following issue
> > with lto.priv symbols:
> >
> > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
> > error: libbackend.a(generic-match.o): multiple definition of
> > 'wi::to_wide(tree_node const*) [clone .part.0] [clone .lto_priv.0]'
> > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
> > libbackend.a(gimple-match.o): previous definition here
> > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
> > error: libbackend.a(generic-match.o): multiple definition of
> > 'TYPE_VECTOR_SUBPARTS(tree_node const*) [clone .part.0] [clone .lto_priv.0]'
> > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
> > libbackend.a(gimple-match.o): previous definition here
> > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
> > error: libbackend.a(generic-match.o): multiple definition of
> > 'vec<constructor_elt, va_gc, vl_embed>::operator[](unsigned int) [clone
> > .part.0] [clone .lto_priv.0]'
> >
> > Any idea what was I doing wrong?
>
> Nothing in particular I think - you're just hitting the issue that LTO
> produces new symbols and that those
> can obviously clash. Giuliano hit the very same issue. When not
> doing partial links those internal
> symbols pose no problem, but with -r -flinker-output=nolto-rel and
> re-linking the produced objects
> they obviously do. ELF has no solution for this though, but I think
> we could strip those from the
> partially linked object - if WPA would give us a list of objects the
> link step could postprocess
> the object with objcopy or maybe a custom linker script could do the
> trick as well.
Oh, and the "best" solution would be to avoid involving the linker
when doing -r -flinker-output=nolto-rel but instead have the assembler
produce the single object from the multiple LTRANS assembly snippets
which could then use local labels instead of symbols for these.
> So your workaround is to only ever have a single LTO produced object
> file participating in the
> final links ;)
>
> Richard.
>
> >
> > Martin
