On Thu, 2015-06-18 at 11:05 +0200, Uros Bizjak wrote: > On Thu, Jun 18, 2015 at 10:59 AM, James Greenhalgh > <james.greenha...@arm.com> wrote: > > >> > Hello! > >> > > >> > Following patch fixes: > >> > > >> > cp_lto_pr65276_1.o: In function > >> > `std2::runtime_error::~runtime_error()':^M > >> > pr65276_1.C:(.text._ZN4std213runtime_errorD2Ev[_ZN4std213runtime_errorD5Ev]+0x8): > >> > undefined reference to `std2::exception::~exception()'^M > >> > cp_lto_pr65276_1.o: In function > >> > `std2::runtime_error::~runtime_error()':^M > >> > pr65276_1.C:(.text._ZN4std213runtime_errorD0Ev[_ZN4std213runtime_errorD5Ev]+0xc): > >> > undefined reference to `std2::exception::~exception()'^M > >> > cp_lto_pr65276_1.o:(.rodata._ZTVN4std29exceptionE[_ZTVN4std29exceptionE]+0x10): > >> > undefined reference to `std2::exception::~exception()'^M > >> > cp_lto_pr65276_1.o:(.rodata._ZTVN4std29exceptionE[_ZTVN4std29exceptionE]+0x18): > >> > undefined reference to `std2::exception::~exception()'^M > >> > collect2: error: ld returned 1 exit status^M > >> > > >> > link error with g++.dg/lto/pr65276 testcase. > >> > > >> > 2015-06-16 Uros Bizjak <ubiz...@gmail.com> > >> > > >> > PR testsuite/65944 > >> > * g++.dg/lto/pr65276_0.C: Add std2::exception::~exception() function. > >> > > >> > Tested on x86_64-linux-gnu CentOS 5.11 (where linking failed) and > >> > Fedora 22 (where linking didn't fail). > >> > > >> > OK for mainline and gcc-5 branch? > >> > >> Now committed as obvious. > > > > This patch causes failures in arm-none-linux-gnueabihf testing: > > > > PASS->FAIL: g++.dg/lto/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o link, > > -flto -O0 -std=c++11 > > > > .../arm-none-linux-gnueabihf/obj/gcc4/gcc/testsuite/g++2/../../xg++ > > -B.../arm-none-linux-gnueabihf/obj/gcc4/gcc/testsuite/g++2/../../ > > cp_lto_pr65276_0.o cp_lto_pr65276_1.o -fno-diagnostics-show-caret > > -fdiagnostics-color=never -nostdinc++ > > -I.../arm-none-linux-gnueabihf/obj/gcc4/arm-none-linux-gnueabihf/libstdc++-v3/include/arm-none-linux-gnueabihf > > > > -I.../arm-none-linux-gnueabihf/obj/gcc4/arm-none-linux-gnueabihf/libstdc++-v3/include > > -I.../gcc/libstdc++-v3/libsupc++ -I.../gcc/libstdc++-v3/include/backward > > -I.../gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -flto -O0 > > -std=c++11 > > -L.../arm-none-linux-gnueabihf/obj/gcc4/arm-none-linux-gnueabihf/./libstdc++-v3/src/.libs > > > > -B.../arm-none-linux-gnueabihf/obj/gcc4/arm-none-linux-gnueabihf/./libstdc++-v3/src/.libs > > > > -L.../arm-none-linux-gnueabihf/obj/gcc4/arm-none-linux-gnueabihf/./libstdc++-v3/src/.libs > > -o g++-dg-lto-pr65276-01.exe > > cp_lto_pr65276_1.o (symbol from plugin): In function `typeinfo for > > std2::runtime_error': > > (.text+0x0): multiple definition of `typeinfo name for std2::exception' > > cp_lto_pr65276_0.o (symbol from plugin):(.text+0x0): first defined here > > cp_lto_pr65276_1.o (symbol from plugin): In function `typeinfo for > > std2::runtime_error': > > (.text+0x0): multiple definition of `typeinfo for std2::exception' > > cp_lto_pr65276_0.o (symbol from plugin):(.text+0x0): first defined here > > collect2: error: ld returned 1 exit status > > compiler exited with status 1 > > output is: > > cp_lto_pr65276_1.o (symbol from plugin): In function `typeinfo for > > std2::runtime_error': > > (.text+0x0): multiple definition of `typeinfo name for std2::exception' > > cp_lto_pr65276_0.o (symbol from plugin):(.text+0x0): first defined here > > cp_lto_pr65276_1.o (symbol from plugin): In function `typeinfo for > > std2::runtime_error': > > (.text+0x0): multiple definition of `typeinfo for std2::exception' > > cp_lto_pr65276_0.o (symbol from plugin):(.text+0x0): first defined here > > collect2: error: ld returned 1 exit status > > I discussed this patch privately with Jon, where he suggested that the > approach is OK. The patch also works for me on both, CentOS 5.11 and > Fedora 22. > > I'm out of ideas why this doesn't work on your system. Can you investigate it? > > Uros.
I am seeing something similar to this with arm targets, and I don't think it's a problem with the test. From my limited understanding of the ARM C++ ABI, there should not be any typeinfo definitions in the object for pr65276_1.C. I am seeing strong typeinfo definitions in the objects for both pr65276_0.C and pr65276_1.C though, which is what's causing the error me.
