On Mon, Mar 4, 2019 at 8:41 AM Christophe Lyon
<christophe.l...@linaro.org> wrote:
> On Wed, 20 Feb 2019 at 02:58, Jason Merrill <ja...@redhat.com> wrote:
> >
> > A type in an anonymous namespace can never be merged with one from
> > another translation unit, so a member of such a type is always its own
> > prevailing decl.
> >
> > I don't really understand the LTO concept of prevailing decl, or why we 
> > don't
> > get here if the destructor is defined, but this seems reasonable and fixes 
> > the
> > bug.
> >
> > Tested x86_64-pc-linux-gnu.  OK for trunk?
> >
> >         * lto-symtab.c (lto_symtab_prevailing_virtual_decl): Return early
> >         for a type in an anonymous namespace.
> > ---
> >  gcc/lto/lto-symtab.c                 |  8 ++++++--
> >  gcc/testsuite/g++.dg/lto/pr88049_0.C | 16 ++++++++++++++++
> >  gcc/lto/ChangeLog                    |  6 ++++++
> >  3 files changed, 28 insertions(+), 2 deletions(-)
> >  create mode 100644 gcc/testsuite/g++.dg/lto/pr88049_0.C
> >
> > diff --git a/gcc/lto/lto-symtab.c b/gcc/lto/lto-symtab.c
> > index 22da4c78b8c..343915c3cec 100644
> > --- a/gcc/lto/lto-symtab.c
> > +++ b/gcc/lto/lto-symtab.c
> > @@ -1085,8 +1085,12 @@ lto_symtab_prevailing_virtual_decl (tree decl)
> >  {
> >    if (DECL_ABSTRACT_P (decl))
> >      return decl;
> > -  gcc_checking_assert (!type_in_anonymous_namespace_p (DECL_CONTEXT (decl))
> > -                      && DECL_ASSEMBLER_NAME_SET_P (decl));
> > +
> > +  if (type_in_anonymous_namespace_p (DECL_CONTEXT (decl)))
> > +    /* There can't be any other declarations.  */
> > +    return decl;
> > +
> > +  gcc_checking_assert (DECL_ASSEMBLER_NAME_SET_P (decl));
> >
> >    symtab_node *n = symtab_node::get_for_asmname
> >                      (DECL_ASSEMBLER_NAME (decl));
> > diff --git a/gcc/testsuite/g++.dg/lto/pr88049_0.C 
> > b/gcc/testsuite/g++.dg/lto/pr88049_0.C
> > new file mode 100644
> > index 00000000000..7ac3618c2c8
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/lto/pr88049_0.C
> > @@ -0,0 +1,16 @@
> > +// PR c++/88049
> > +// { dg-lto-do link }
> > +// { dg-lto-options {{ -flto -O2 -w }} }
> > +// { dg-extra-ld-options -r }
> > +
> > +template <typename> class a;
> > +class b {};
> > +template <typename e> a<e> d(char);
> > +template <typename> class a : public b {
> > +public:
> > +  virtual ~a();
> > +};
> > +namespace {
> > +  class f;
> > +  b c = d<f>(int());
> > +} // namespace
>
>
> Hi Jason,
>
> On bare-metal targets (arm, aarch64 using newlib), I'm using dejagnu's
> testglue, which makes this new test fail because it also uses
> g++_tg.o, leading to:
> /arm-none-eabi/bin/ld: warning: incremental linking of LTO and non-LTO
> objects; using -flinker-output=nolto-rel which will bypass whole
> program optimization
>
> Is there a way to avoid that (besides not using testglue) ?

Does adding

// { dg-require-effective-target lto_incremental }

to the testcase help?

Jason

Reply via email to