<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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?</div>

<div> </div>
<div>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?)</div>

<div> </div>
<div>Thanks.</div>
<div> </div>
<div>-John<br></div>
<div class="gmail_quote">On Wed, Dec 2, 2009 at 7:20 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im"><br>On Dec 2, 2009, at 6:34 PM, John Thompson wrote:<br><br>> 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.<br>
><br>> 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?<br><br></div>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.<br>
<br>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.<br>

<div class="im"><br>> 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.<br>
<br></div>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.<br>
<font color="#888888"><br>John.</font></blockquote></div><br><br clear="all"><br>-- <br>John Thompson<br><a href="mailto:John.Thompson.JTSoftware@gmail.com">John.Thompson.JTSoftware@gmail.com</a><br><br>