[cfe-commits] [PATCH] Don't apply function attributes to the return type

[John McCall]

On Feb 23, 2010, at 5:34 PM, Charles Davis wrote:

> John McCall wrote:
>> On Feb 23, 2010, at 3:40 PM, Charles Davis wrote:
>>> John McCall wrote:
>>>> Is this actually what gcc does?  The documentation I've seen suggested that gcc tries to apply a function type attribute in the decl spec to the return type if it's a function pointer, and otherwise tries to apply it to the function itself.  But maybe I'm misinterpreting it, or maybe that documentation is incorrect:
>>>> http://developer.apple.com/mac/library/DOCUMENTATION/DeveloperTools/gcc-4.0.1/gcc/Attribute-Syntax.html#Attribute-Syntax
>>>> 
>>>> At any rate, please do more investigation.  If this is the right thing to do, we'll do it, but until we have a clear idea what on earth gcc is doing here, I'd rather hold off.
>>> I did some experimentation with GCC 4.2. The results are on the page for
>>> PR6408. For your convenience, I reiterate them here:
>> 
>> I did read the bug commentary before I posted.  My question is whether this behavior is intentional or extensional :).  That is, is this an *aspect* of the rule that gcc uses, or merely a *consequence*?
>> 
>> In particular, it is quite possible that gcc checks if the innermost declarator is a function (or pointer to function?) and, if so, applying CCs in the declaration-specifiers to that function rather than the type in the type-specifiers.  That's distinguishable from "don't apply CCs to the return type" in several ways:
>> 
>> typedef void ftype(int);
>> ftype __attribute__((fastcall)) **fpp; // is this accepted?
>> ftype __attribute__((fastcall)) *fpa[10];  // or this?
> For both tof these, GCC tried to apply it to the pointer (or the array,
> in the second case).
>> ftype __attribute__((fastcall)) (**fpfpp)(int); // and which function does the attribute affect here?
> Neither. For one thing, GCC didn't like that this function returns a
> function. This probably confused GCC, and so it ended up applying it to
> the pointer itself (which, of course, fails).
> 
> Adding an asterisk causes GCC to accept it, but placement of the
> asterisk was important. If it came before the calling convention
> attribute, GCC attached it to the return type (which I determined by
> looking at the generated code for a function of the type to which fpfpp
> points).
> 
> If the asterisk came after, GCC once again fails to apply the attribute,
> but that's because it's trying to apply the attribute to the pointer to
> a function pointer. It understands functions and function pointers, but
> not pointers to function pointers.
> 
> It's interesting how GCC gets this backwards--at least, in my opinion. I
> would think that it would be the other way around, that if the calling
> convention comes before the asterisk, it belongs to the return type, and
> if it comes after, it belongs to the function. My verdict: this is
> definitely extensional behavior.
> 
> How do you come up with this stuff?
>> 
>> Also, what happens in a declaration group?  Does it make the decision separately for each declaration, or is the decision made for the first declaration carried over to subsequent declarations?
> For a function typedef (not a function *pointer* typedef), it depends on
> where the asterisk is. If the calling convention comes before the
> asterisk, the attribute applies to the whole group. If it comes after,
> it only applies to the first one.
> 
> For function pointer typedefs, it always applies the attribute to the
> whole group.
>> 
>> I accept that the rule I implemented earlier is incorrect;  I just want to know what the correct rule is before we start hacking in more things that make individual projects work.
> Good point. Hope this helps.

Okay.  All of this is indeed consistent with the idea that function type attributes in the declaration-specifiers always apply to the entire declaration and never to the return type, so your patch seems fine to me.  The remaining problems are quite possibly just errors in where the parser is grouping attributes in declarators;  I'd suggest starting by looking at that and making sure it's sane.

John.