[cfe-dev] vector function return type

[John Thompson]

Here's another go at it (fix for bug 5650).  It looks like the code was
already in place for handling attributes for types before the declaration
was finalized.  I basically just hacked up HandleVectorSizeAttr and moved it
to be called from ProcessTypeAttributeList instead of ProcessDeclAttribute.

I also revised PrintVector in the type printer to put the vector_size
attribute first, and revised the test in Sema/vector-init.c.

Is anything else needed for this?
-John
On Thu, Dec 3, 2009 at 7:24 AM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

> Thanks, it makes sense.  I'll see if I can put in support for handling this
> attribute as part of setting up the initial declaration.
>
> Actually, what I really want is to implement Altivec vector support (i.e.
> the "vector" keyword and the associated built-in functions), but I figured
> fixing this was a useful stop along the way.
>
> In a previous posting to this list about Altivec support, I was pointed to
> the vector_size attribute, and some gcc docs about __vector (it seems we
> don't have __vector yet), but I didn't really hear a yea or nay about
> putting in "vector" (and "__vector").  Our gcc-based PS3 compiler implements
> "vector" directly (i.e. no typedef or #define enabled in altivec.h).  I
> understand this will require a look-ahead to see if there is a numeric type
> following "vector".  Would it be okay for me to take a crack at doing this?
>
> And looking father ahead, there are some areas where gcc diverges from the
> Altivec standard.  Would we want to fix this in Clang too?  (I.e. support
> both the gcc form and the standard, hopefully without requiring a new
> option?)
>
> Thanks.
>
> -John
>   On Wed, Dec 2, 2009 at 7:20 PM, John McCall <rjmccall at apple.com> wrote:
>
>>
>> On Dec 2, 2009, at 6:34 PM, John Thompson wrote:
>>
>> > I'm looking at bug 5650 about using vector return types on functions,
>> which is kind of difficult, not knowing all the ramifications of the type
>> system.
>> >
>> > For example, I need to change the return type of a function declaration,
>> but there aren't any accessors for that.  Is that because it's complicated?
>>
>> Yes.  Among other problems, the redeclaration logic will be completely
>> wrong if you take a fully-formed function declaration and change its type.
>>  You really need to find the attribute before building the declaration, or
>> at least before doing redeclaration checks on it.
>>
>> Meta-question:  are we sure we want to allow this syntax?  Is this a gcc
>> compatibility issue?  Because gcc's habit of pushing attributes from decls
>> to random component types is already really bogus, and I'm hesitant to add
>> to that when there's a perfectly reasonable solution (typedef the vector
>> type) already.
>>
>> > For example, since the QualType can apparently point to something, is
>> that allocated storage, such that it would leak if I just assigned to it, or
>> is the memory managed elsewhere?  Sorry, I probably should just study it
>> some more.
>>
>> Types are immutable;  the ASTContext uniques types based on their
>> components, and then the type object lives forever as part of the
>> ASTContext.  So you don't have to worry about leaking memory, but you also
>> won't be able to naively modify types like this.
>>
>> John.
>
>
>
>
>  --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20091204/953cb70c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vecreturn1.patch
Type: application/octet-stream
Size: 9437 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20091204/953cb70c/attachment.obj>