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.
