[cfe-dev] vector function return type

[John Thompson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20091203/3768440f/attachment.html>