public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michael Daniels <mdaniels@qnx.com>
To: "ubizjak@gmail.com" <ubizjak@gmail.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	"james.greenhalgh@arm.com" <james.greenhalgh@arm.com>,
	"jwakely@redhat.com"	<jwakely@redhat.com>
Subject: Re: [PATCH, testsuite]: Fix PR 65944, FAIL: g++.dg/lto/pr65276: undefined reference to std2::exception::~exception()
Date: Tue, 02 Feb 2016 03:09:00 -0000	[thread overview]
Message-ID: <1454382573.3614.27.camel@mdaniels> (raw)
In-Reply-To: <CAFULd4aOJ-HLnO1BjbpxEcH8feXOJSoJ=XbgGRKfKHD3rzObgA@mail.gmail.com>

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.

      parent reply	other threads:[~2016-02-02  3:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-16 15:32 Uros Bizjak
2015-06-17 10:17 ` Uros Bizjak
2015-06-18  9:05   ` James Greenhalgh
2015-06-18  9:32     ` Uros Bizjak
2015-06-18  9:43       ` Uros Bizjak
2016-02-02  3:09       ` Michael Daniels [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1454382573.3614.27.camel@mdaniels \
    --to=mdaniels@qnx.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=james.greenhalgh@arm.com \
    --cc=jwakely@redhat.com \
    --cc=ubizjak@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).