"Amker.Cheng" <amker.cheng@xxxxxxxxx> 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
