This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: pr27650 - dllimport of virtual methods broken.
- From: Danny Smith <dannysmith at clear dot net dot nz>
- To: 'Mark Mitchell' <mark at codesourcery dot com>, 'Carlos O'Donell' <carlos at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org, jason at redhat dot com, nathan at codesourcery dot com
- Date: Thu, 14 Sep 2006 14:34:22 +1200
- Subject: RE: pr27650 - dllimport of virtual methods broken.
> From: Mark Mitchell
> Carlos O'Donell wrote:
> > Is any of you able to give some comments on pr27650
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650
> >
> > In particular I am interested in an opinion of Danny's fix.
> >
> > http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01504.html
> >
> The cp/decl2.c change also seems less than ideal. The key
> invariant is
> that virtual functions can't be dllimport'd. So, I think we
> should mark
> them that way when they're declared, perhaps in grokfndecl or in
> cp_finish_decl.
>
> It could be that I'm missing something, though; Danny might want to
> debate my conclusions.
The problem I had was with the second case below. We don't know if a
method is implicitly virtual
until search.c:look_for_overrides_r). Would t be better to unset
DECL_DLLIMPORT_P (and remove the attribute as well) there?
// Don't import explicitly virtual method.
struct base
{
virtual void key_method();
__attribute__((dllimport)) virtual ~base();
};
void base::key_method() {}
// Nor an implicitly virtual method.
struct derived : public base
{
void key_method();
__attribute__((dllimport)) ~derived();
};
void derived::key_method() {}
Danny