[cfe-dev] Parameter check question
rjmccall at apple.com
Tue Oct 6 18:40:21 CDT 2009
Tanya Lattner wrote:
> On Oct 6, 2009, at 3:50 PM, John McCall wrote:
>> Tanya Lattner wrote:
>>> On Oct 5, 2009, at 2:58 PM, Douglas Gregor wrote:
>>>> On Oct 5, 2009, at 2:37 PM, Tanya Lattner wrote:
>>>>> I want to do a check on function parameters similar to the
>>>>> "err_arg_with_address_space" check that I added
>>>>> in ActOnParamDeclarator (r83165). However, this time, I only want
>>>>> to perform the check if the function has a specific attribute.
>>>>> Is ActOnParamDeclarator the right place? I'm not seeing a way to
>>>>> get the function attribute there. Or, any suggestion on where to
>>>>> add this?
>>>> ActOnParamDeclarator won't work, since that gets can get called by
>>>> the parser before we've seen the function attributes. I suggest
>>>> putting this check into ActOnFunctionDeclarator (e.g., where we
>>>> check for parameters of "void" type).
>>> Awesome, thanks! At this point in ActOnFunctionDeclarator, do
>>> parameters know about their attributes? Specifically addr space
>>> qualifiers. I'm thinking no because it always seems to think the
>>> param's in addr space 0, but when I dump the QualType I can clearly
>>> see the addr space attribute and its non zero, but I assume it just
>>> hasn't been processed yet.
>> ActOnFunctionDeclarator doesn't get called until all the parameters
>> have finished parsing, so all the attributes, address spaces, etc.
>> should be present.
>> Can you post a code example where it thinks the parameter is in
>> address space 0 (I assume getAddressSpace() is returning 0)?
> Yes, I'm using getAddressSpace().
> Here is a simple example:
> __attribute__((annotate("random"))) void
> foo(__attribute__((address_space(1))) int *x);
I'm pretty sure this is legal in TR18037. Like 'const', address spaces
can apply at any point in a type; an address-space-qualified type says
that the object is stored in a particular address space. So x is a
pointer (stored in the generic address space) to an object of type int
(stored in address space 1).
The codegen implications of address spaces accrue to pointers into that
address space, which is why you can't have auto variables with direct
address space qualifications.
If for some reason you want to implement a stricter condition than
TR18037 and forbid pointers into non-generic address spaces, you'll need
to pull off the outermost pointer from the type.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev