[cfe-dev] Parameter check question

John McCall rjmccall at apple.com
Tue Oct 6 16:40:21 PDT 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:
>>>>
>>>>> Hello,
>>>>>
>>>>> 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.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20091006/cbbb1839/attachment.html>


More information about the cfe-dev mailing list