This is the mail archive of the gcc-patches@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: [PATCH] Fix PR C++/9021 and 11005


 --- Jason Merrill <jason@redhat.com> wrote: > Hmm, I'm not sure this is right,
either.  Do we really want to allow people
> to keep adding attributes to a class?
> 
> I think it probably makes sense to use your patch, but make it conditional
> on whether or not the class is complete; if it is, then specifying
> additional attributes is an error.
> 
> Thoughts?
> 

Maybe. This rule:
"If !COMPLETE_TYPE_P, merge attributes, else ignore the
new attributes"
works with the usages of dllimport that I am familiar with, but doesn't
appear to be needed for dllimport anyway (see third case below).

The most common usage in the dll[im/ex]port context is this:

// Case 1:
// Class definition  with DLLIMPORT attribute, followed by a redeclaration
//  (or declaration as friend) without the attribute.

struct __attribute__((dllimport)) Foo1
{
  int foo1fun(void) const;
};

struct Bar1 
{
  int useFoo1 (const Foo1& _x);
};

struct Foo1;	// Redeclaration: Old attributes should be retained,
		// and not overwritten with NULL_TREE

int Bar1::useFoo1 (const Foo1& _x)
{
  return  _x.foo1fun();
}

void test1()
{
  Bar1 aBar1;
  Foo1 aFoo1;
  aBar1.useFoo1 (aFoo1);
}


// Case 2:
// This usage is also accepted by native compiler and is useful for
// keeping all the 'target' attributes in a single place. 

// Forward declaration with DLLIMPORT attribute
// followed by definition without DLLIMPORT attribute.


// FooBar-dll.h
// All the dll attribute stuff is put here
struct __attribute__((__dllimport__)) Foo2;
struct __attribute__((__dllimport__)) Faz2;
struct __attribute__((__dllimport__)) Foz2;


// FooBar.C
#ifdef _DLLAPI
#include "FooBar-dll.h"
#endif

struct Foo2;

struct Bar2 
{
  int useFoo2 (const Foo2&);
};

struct Foo2  // This gets attribute from the forward declaration
{
  int foo2fun(void) const;
};

int Bar2::useFoo2(const Foo2& _x)
{
  return  _x.foo2fun();
}

void test2()
{
  Bar2 aBar2;
  Foo2 aFoo2;
  aBar2.useFoo2 (aFoo2);
}



// Case 3:
// Finally, this is the case where we try to add an attribute 
// to a complete type.

// Definition  without attribute, followed by a redeclaration
// with  attribute.


struct Foo3
{
  int foo3fun(void) const;
};

struct  __attribute__((dllimport)) Foo3; // Ignore attribute?

struct Bar3 
{
  int useFoo3 (const Foo3& _x);
};


int Bar3::useFoo3 (const Foo3& _x)
{
  return  _x.foo3fun();
}


void test3()
{
  Bar3 aBar3;
  Foo3 aFoo3;
  aBar3.useFoo3 (aFoo3);
}

Even without a check for COMPLETE_TYPE_P before merging attributes,
foo3fun doesn't get marked as dllimport.

Danny
 


> Jason
>  

http://personals.yahoo.com.au - Yahoo! Personals
New people, new possibilities. FREE for a limited time.


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