This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [LTO] Question about comdat linkage of implicit ctor and dtor.
- From: Rafael Espindola <espindola at google dot com>
- To: Doug Kwan (éæå) <dougkwan at google dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 21 Nov 2008 09:09:16 +0000
- Subject: Re: [LTO] Question about comdat linkage of implicit ctor and dtor.
- References: <498552560811201411g73da76d4p1510a02a63c0ecb@mail.gmail.com>
2008/11/20 Doug Kwan (éæå) <dougkwan@google.com>:
> Hi Mark,
>
> I ran into to a bug where ILs in different files contain identical
> DECLs of an implicit virtual destructor of an instantiated template
> class. That happened in the BINFOs. Rafael just removed the BINFOs
> in the IL but the underlying problem is the there. The problem was
> caused by lack of vague linkage indication in the DECLs so LTO
> complained about multiple definition. Actually the destructor was not
> defined in either of the object files. It was not emitted. So gcc
> did to called import_export_decl to determine the linkage. As far as
> I know it is an error to re-define an implicitly declared
> constructor/destructor. So gcc should be able to determine the
> linkage early, when such a constructor/destructor is declared
> implictly. I tried to look at the logic of import_export_decl and it
> is not simple because of additional interactions of the -frepo and
> -fweak. Do you know if it is safe to have import_export_decl to
> compute the right linkage setting early for implicit constructors and
> destructors? Thanks.
Unfortunately I am not familiar with the C++ FE so I don't know when
it safe to decide the linkage. It must be possible to do so before
writing to disk, since we (at least implicitly) do so in a normal
compilation when printing assembly :-)
> -Doug
>
Cheers,
--
Rafael Avila de Espindola
Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047