This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]