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

2016-02-01 Thread 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
>  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  
> >> >
> >> > 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.


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

2015-06-18 Thread Uros Bizjak
On Thu, Jun 18, 2015 at 11:05 AM, Uros Bizjak  wrote:

>> 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?

FYI, patched testcase compiles to following assembly on CentOS 5.11:

cp_lto_pr65276_0.o: file format elf64-x86-64

Disassembly of section .text:

 <_ZN4std29exceptionD1Ev>:
  0:   55  push   %rbp
  1:   48 89 e5mov%rsp,%rbp
  4:   48 83 ec 10 sub$0x10,%rsp
  8:   48 89 7d f8 mov%rdi,0xfff8(%rbp)
  c:   ba 00 00 00 00  mov$0x0,%edx
   d: R_X86_64_32  _ZTVN4std29exceptionE+0x10
 11:   48 8b 45 f8 mov0xfff8(%rbp),%rax
 15:   48 89 10mov%rdx,(%rax)
 18:   b8 00 00 00 00  mov$0x0,%eax
 1d:   85 c0   test   %eax,%eax
 1f:   74 0c   je 2d <_ZN4std29exceptionD1Ev+0x2d>
 21:   48 8b 45 f8 mov0xfff8(%rbp),%rax
 25:   48 89 c7mov%rax,%rdi
 28:   e8 00 00 00 00  callq  2d <_ZN4std29exceptionD1Ev+0x2d>
   29: R_X86_64_PC32   _ZdlPv+0xfffc
 2d:   c9  leaveq
 2e:   c3  retq
 2f:   90  nop

0030 <_ZN4std29exceptionD0Ev>:
 30:   55  push   %rbp
 31:   48 89 e5mov%rsp,%rbp
 34:   48 83 ec 10 sub$0x10,%rsp
 38:   48 89 7d f8 mov%rdi,0xfff8(%rbp)
 3c:   48 8b 45 f8 mov0xfff8(%rbp),%rax
 40:   48 89 c7mov%rax,%rdi
 43:   e8 00 00 00 00  callq  48 <_ZN4std29exceptionD0Ev+0x18>
   44: R_X86_64_PC32
_ZN4std29exceptionD1Ev+0xfffc
 48:   48 8b 45 f8 mov0xfff8(%rbp),%rax
 4c:   48 89 c7mov%rax,%rdi
 4f:   e8 00 00 00 00  callq  54 <_ZN4std29exceptionD0Ev+0x24>
   50: R_X86_64_PC32   _ZdlPv+0xfffc
 54:   c9  leaveq
 55:   c3  retq

Unpatched testcase produces empty object file.

Uros.


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

2015-06-18 Thread Uros Bizjak
On Thu, Jun 18, 2015 at 10:59 AM, James Greenhalgh
 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  
>> >
>> > 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.


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

2015-06-18 Thread James Greenhalgh
On Wed, Jun 17, 2015 at 11:04:24AM +0100, Uros Bizjak wrote:
> On Tue, Jun 16, 2015 at 5:13 PM, Uros Bizjak  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  
> >
> > 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.

Hi,

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

Thanks,
James



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

2015-06-17 Thread Uros Bizjak
On Tue, Jun 16, 2015 at 5:13 PM, Uros Bizjak  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  
>
> 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.

Uros.