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.
So your workaround is to only ever have a single LTO produced object
file participating in the
final links ;)
Richard.
>
> Martin
