Re: make check failed for builtins testcases when lto enabled

[Ian Lance Taylor <iant at google dot com>]

"Amker.Cheng" <amker.cheng@gmail.com> writes:

> I noticed there are some builtins testcases failed in my "make
> check-gcc" when lto enabled.
> the command line like:
>
> xgcc ...
> .../gcc/testsuite/gcc.c-torture/execute/builtins/strlen.c
> .../gcc/testsuite/gcc.c-torture/execute/builtins/strlen-lib.c
> .../gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c
> -w -O2
> -flto -flto-partition=none
> -lm -specs=rdimon.specs -lrdimon -lc -lg -lrdimon -mthumb -mcpu=cortex-m3
> -o .../gcc/testsuite/gcc/strlen.x6
>
> this failed testcase always complains:
> /tmp/ccw8n1Wt.lto.o: In function `strlen':
> ccYaDFzm.o:(.text+0x0): multiple definition of `strlen'
> .../lib/gcc/arm-none-eabi/4.7.0/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-strlen.o):strlen.c:(.text+0x0):
> first defined here
> collect2: error: ld returned 1 exit status
>
> There are a copy of strlen in c source file and a copy in libc.a.
> Seems gcc/lto always link libc.a and find the library copy first,
> which results in re-definition error.
>
> So any suggestions? Thanks very much.
>
> BTW, the testcase is ok without"-flto -flto-partition=none" specified.

I don't understand why this would happen, because I don't understand why
gcc/lto would link libc.a in first.  It shouldn't.  If this is indeed
the problem, then it presumably is not happening on other targets
because on most targets there is no LTO information for libc.a.  I would
recommend opening a bug report for this with enough input files (e.g.,
libc.a) to recreate the problem.

Ian