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

[John McCall]

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?
ftype __attribute__((fastcall)) (**fpfpp)(int); // and which function does the attribute affect here?

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?

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.

John.