Attributes

Sean Hunt rideau3@gmail.com
Mon Jul 5 22:59:00 GMT 2010


Hey GCC devs,

My name is Sean Hunt and I'm currently refactoring the 
attribute-handling system in clang, in order to better support C++0x[1] 
attributes and make attributes in general much easier to follows. One of 
the major issues I'm having is that there are a number of cases where 
concessions are made to GCC attributes for of compatibility with GCC but 
where the exact basis for making these concessions is either unclear or 
listed in the GCC spec[2] as being a case of things not implemented in 
GCC. More importantly, these concessions are prohibited from being made 
in C++0x.

In a few cases, the incompatibilities are visible in the specifications, 
for instance, with the noreturn attribute:

     void foo () [[noreturn]]; // wrong per spec
     void foo [[noreturn]] (); // right per spec
     [[noreturn]] void foo (); // right per spec

     void foo () __attribute__((noreturn)); // right per spec
     void foo __attribute__((noreturn)) (); // works
     __attribute__((noreturn)) void foo (); // works

It's obvious that the first example of each kind (noreturn appearing 
after the function declarator) must be accepted if it's a GCC attribute 
and not if it's a C++0x attributes. The later two (noreturn appearing 
before the declaration or after the identifier) must be accepted for 
C++0x attributes, but it's not clear if the GCC syntax being accepted is 
an accident or by design.

There are more complex scenarios, such as if the function returns a 
pointer and the attribute appears between the pointer declarator and the 
identifier:

    void * [[noreturn]] foo (); // wrong per spec
    void * __attribute__((noreturn)) foo (); // works

This also works with GCC syntax, but once again it is very unclear 
whether it's actually supposed to.

Another incompatibility is with array declarators:

int i [] [[aligned(4)]]; // wrong per spec
int i [] __attribute__(align(4)); // right per spec

Is anyone currently working on C++0x attributes in GCC and, if not, is 
there anyone who can help me through what we should and shouldn't accept 
in clang?

Thanks,
Sean



More information about the Gcc mailing list