Attributes

Attributes

[Sean Hunt]

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

Re: Attributes

[Ian Lance Taylor]

Sean Hunt <rideau3@gmail.com> writes:

>     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.

As far as I can see they are both documenated as working at
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Attribute-Syntax.html , so I
think it is by design.

> 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?

I don't know the answer to this.  It's clear that C++0x attributes are
not the same as GNU attributes.

Ian

Re: Attributes

[Sean Hunt]

On 07/10/2010 03:56 PM, Ian Lance Taylor wrote:
> Sean Hunt<rideau3@gmail.com>  writes:
>
>>      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.
>
> As far as I can see they are both documenated as working at
> http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Attribute-Syntax.html , so I
> think it is by design.

The problem is that it is not clear if that is intended, or merely an 
accident. The spec is rather unclear about a number of things.

>> 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?
>
> I don't know the answer to this.  It's clear that C++0x attributes are
> not the same as GNU attributes.
>
> Ian

Yes. I'm trying to determine which parts of GCC attributes are merely 
accidents and don't really need implementation, as there are a lot of 
situations where GCC attributes (as implemented) are significantly more 
liberal than C++0x attributes are. This will be an issue that GCC 
developers will encounter when an effort is made to implement 
attributes; I would like to see what discussion can be had before I go 
ahead and reimplement the attribute codepaths within clang.

Sean

Re: Attributes

[Ian Lance Taylor]

Sean Hunt <rideau3@gmail.com> writes:

> On 07/10/2010 03:56 PM, Ian Lance Taylor wrote:
>> Sean Hunt<rideau3@gmail.com>  writes:
>>
>>>      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.
>>
>> As far as I can see they are both documenated as working at
>> http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Attribute-Syntax.html , so I
>> think it is by design.
>
> The problem is that it is not clear if that is intended, or merely an
> accident. The spec is rather unclear about a number of things.

I'm not sure what sort of answer you are looking for.  Attributes were
implemented in gcc without any sort of design or spec.  They were and
are used in many programs.  We don't want to break those programs.  The
current documentation describes how attributes work, and is intended to
be a guide both for gcc maintainers and for gcc users.  The
documentation describes for users how attributes may be used, and
describes for maintainers what is supposed to work.

So when you ask whether the syntax is intended or is an accident, the
answer is more or less that both are the case.  It's not an either/or
situation.


>>> 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?
>>
>> I don't know the answer to this.  It's clear that C++0x attributes are
>> not the same as GNU attributes.
>
> Yes. I'm trying to determine which parts of GCC attributes are merely
> accidents and don't really need implementation, as there are a lot of
> situations where GCC attributes (as implemented) are significantly
> more liberal than C++0x attributes are. This will be an issue that GCC
> developers will encounter when an effort is made to implement
> attributes; I would like to see what discussion can be had before I go
> ahead and reimplement the attribute codepaths within clang.

I'm not working on implementing C++0x attributes in GCC.  However, my
answer would be that you should implement gcc attributes according to
the gcc docs and implement C++0x attributes according to the C++0x final
committee draft.  They are obviously related, but they are not the same
thing.  It would be a mistake to implement them both in the same way, at
least when it comes to syntax.

Ian

Re: Attributes

[Joseph S. Myers]

I refer you to the various issues I have raised with attributes proposals 
in WG14 in the past, some at least of which have also been forwarded to 
WG21.  The committees have generally chosen not to listen to compatibility 
concerns, except insofar as WG14 ended up not adopting general attribute 
syntax at all but instead adding new keywords for some particular uses of 
attributes.

I also quote here something I sent off-reflector to Herb Sutter 
(Microsoft) last September (see in particular the first paragraph 
regarding treating [[]] as having clearly separate rules from 
__attribute__):

  [...] I'm also concerned about things for users.  If I implement the 
  proposals in GCC, compatibility with existing code would inevitably mean 
  that __attribute__ follows existing rules for how it binds to syntax 
  constructs, and [[]] follows the different C1x rules, and 
  __attribute__((noreturn)) is part of the type system, and [[noreturn]] 
  isn't.  This avoids breaking existing code, but is bound to confuse users 
  when they try to change syntax (likely with macros such as those you 
  mention) if they happened to be using cases where the two syntaxes bind 
  differently.  When you have two similar but incompatible ways of doing 
  something, you have a no win situation for users - and it's not WG14's job 
  to create work for front-end writers implementing the different modes for 
  compatibility with different code, they should be helping users by 
  avoiding needing the different modes.

  The fact that there are some problems with existing implementations 
  (including bugs where it may not be at all clear what is actually the best 
  thing to do), such as questions of exactly how attributes should interact 
  with the type system, may mean that a standard version cannot be perfectly 
  compatible with existing implementations in all cases.  But by studying 
  what implementations actually do, and what real code using these features 
  does, and what problems have been noted in implementation over the years, 
  it ought to be possible to come up with something friendlier to users (and 
  less ambitious) than the existing proposals.  So far however the proposers 
  of attributes standardization do not seem to have been paying any 
  attention to my points [...]

  Issues we've observed in practice with how attributes interact with the 
  type system include those described in 
  <http://gcc.gnu.org/ml/gcc/2006-10/msg00318.html> and 
  <http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01056.html>.

-- 
Joseph S. Myers
joseph@codesourcery.com