LTO multiple definition failures

[Sandra Loosemore <sandra at codesourcery dot com>]

I've been investigating some LTO-related test failures in a GCC port for 
a DSP target that has not yet been submitted to the FSF.  The bug I've 
hit looks like the same issue with spurious multiple definitions that 
was previously reported on the gcc-help list:

http://gcc.gnu.org/ml/gcc-help/2011-10/msg00201.html

for an ARM EABI target with RTEMS.

I've been trying to duplicate the failure with some other target that 
can be tested "off the shelf".  I haven't found an actual failure yet, 
but I think I see what is causing it.  Here's the analysis I came up 
with using a powerpc-none-eabi target.

I added some instrumentation to ld to make it print out the files it was 
loading from the output of the LTO plugin.  Building

powerpc-none-eabi-gcc 
/scratch/sandra/fsf-mainline/src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1.c 
/scratch/sandra/fsf-mainline/src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1-lib.c 
/scratch/sandra/fsf-mainline/src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c 
-w  -O2 -flto -msim -lm -save-temps -Wl,-Map=foo.map

told me:

Loading 
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/ecrti.o 
OPEN_BFD_NORMAL
Loading 
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/../../../../powerpc-none-eabi/lib/sim-crt0.o 
OPEN_BFD_NORMAL
Loading 
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/crtbegin.o 
OPEN_BFD_NORMAL
Loading 20010124-1.o OPEN_BFD_NORMAL
Loading 20010124-1-lib.o OPEN_BFD_NORMAL
Loading main.o OPEN_BFD_NORMAL
Loading 
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/../../../../powerpc-none-eabi/lib/libm.a 
OPEN_BFD_NORMAL
Loading 
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/libgcc.a 
OPEN_BFD_NORMAL
=start group
Loading 
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/../../../../powerpc-none-eabi/lib/libsim.a 
OPEN_BFD_FORCE
Loading 
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/../../../../powerpc-none-eabi/lib/libc.a 
OPEN_BFD_FORCE
=end group
Loading 
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/libgcc.a 
OPEN_BFD_NORMAL
Loading 
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/crtend.o 
OPEN_BFD_NORMAL
Loading 
/scratch/sandra/fsf-mainline/install/bin/../lib/gcc/powerpc-none-eabi/4.7.0/ecrtn.o 
OPEN_BFD_NORMAL
Loading /tmp/ccxgHMEr.ltrans0.ltrans.o OPEN_BFD_NORMAL

Note that this last file includes a local definition of memcpy, 
originally from 20010124-1-lib.c.  The thing that seems to be leading to 
the multiple definition error is that the startup code for my target, 
and apparently the startup code for the RTEMS target too, includes a 
reference to memcpy, which is resolved to the version from libc.a 
*before* the linker sees the one from the *.ltrans.o file at the end of 
the list.

I'm still finding my way around LTO; can anyone who's more familiar with 
this help narrow down where to look for the cause of this?  I don't even 
know if this is a compiler or ld bug at this point.  I'm not sure I can 
justify spending a lot of time working on this, but I'd at least like to 
get a proper bug report with an easily reproducible test case filed in 
the appropriate Bugzilla.  I looked around and didn't see that the 
previous report of this bug on gcc-help@ ended up recorded anyplace that 
the LTO gurus were likely to remember or do anything about it.  :-S

-Sandra