[PATCH, testsuite]: Fix PR 65944, FAIL: g++.dg/lto/pr65276: undefined reference to std2::exception::~exception()

[Michael Daniels]

On Thu, 2015-06-18 at 11:05 +0200, Uros Bizjak wrote:
> On Thu, Jun 18, 2015 at 10:59 AM, James Greenhalgh
> <james.greenhalgh@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  <ubizjak@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.