<div>+++ lib/Sema/SemaDeclAttr.cpp<span class="Apple-tab-span" style="white-space:pre"> </span>(working copy)</div><div>@@ -4225,7 +4225,7 @@</div><div> QualType BufferTy = getFunctionOrMethodArgType(D, ArgumentIdx);</div>
<div> if (!BufferTy->isPointerType()) {</div><div> S.Diag(Attr.getLoc(), diag::err_attribute_pointers_only)</div><div>- << AttrName;</div><div>+ << Attr.getName();</div><div><br></div>
<div>Did you mean to include this change?</div><div><br></div><div><br></div><div><div>+++ lib/Sema/SemaType.cpp<span class="Apple-tab-span" style="white-space:pre"> </span>(working copy)</div><div>@@ -110,6 +110,13 @@</div>
<div> case AttributeList::AT_PnaclCall: \</div><div> case AttributeList::AT_IntelOclBicc \</div><div> </div><div>+// Microsoft-specific type qualifiers.</div><div>+#define MS_TYPE_ATTRS_CASELIST \</div><div>+ case AttributeList::AT_Ptr32: \</div>
<div>+ case AttributeList::AT_Ptr64: \</div><div>+ case AttributeList::AT_SPtr: \</div><div>+ case AttributeList::AT_UPtr \</div><div>+</div></div><div><br></div><div>Please remove the trailing \ from the end of this macro (and the previous existing one!)</div>
<br><div>+ // Pointer type qualifiers can only operate on pointer types, but not</div><div>+ // pointer-to-member types.</div><div>+ if (!Type->isPointerType() || Type->isMemberPointerType()) {</div><div><br></div>
<div>Member pointer types are not pointer types, so you can drop the || ... part here.</div><div><br></div><div>Also, what if there is type sugar before the pointer type? For instance:</div><div><br></div><div>typedef int *T;</div>
<div>T __ptr32 __sptr P; // ok?</div><div><br></div><div>... or ...</div><div><br></div><div>int *(__ptr32 __sptr p); // ok?</div><div><br></div><div><br></div><div><div>+ // You cannot have both __sptr and __uptr on the same declaration, nor can</div>
<div>+ // you duplicate the attributes.</div><div>+ const AttributedType *AT = dyn_cast<AttributedType>(Type);</div></div><div><br></div><div>What if there is another AttributedType in between? For instance:</div>
<div><br></div><div> int * __sptr __ptr32 __sptr p; // presumably should be rejected, presumably won't be</div><div><br></div><div>You could address both of these by looping over AttributedTypes until you hit a PointerType, or by looking at the form of the pointer by inspecting the TypeProcessingState.</div>
<div><br></div><div><br></div><div>Please add tests for these appearing at the start of the declaration, and after the identifier.</div><br><div class="gmail_quote">On Wed, May 15, 2013 at 1:40 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here is an updated patch that is meant to handle the semantics up to<br>
(but not including) codegen, including test cases.<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, May 14, 2013 at 8:54 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>> wrote:<br>
> On Tue, May 14, 2013 at 8:50 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
>> On Tue, May 14, 2013 at 5:47 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
>> wrote:<br>
>>><br>
>>> On Tue, May 14, 2013 at 8:42 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>>> wrote:<br>
>>> > On Tue, May 14, 2013 at 5:41 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> On Tue, May 14, 2013 at 8:34 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>>> >> wrote:<br>
>>> >> > On Tue, May 14, 2013 at 4:07 PM, Charles Davis <<a href="mailto:cdavis5x@gmail.com">cdavis5x@gmail.com</a>><br>
>>> >> > wrote:<br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> On May 14, 2013, at 4:26 PM, Aaron Ballman wrote:<br>
>>> >> >> ><br>
>>> >> >> >> Do __sptr and __uptr get different manglings?<br>
>>> >> >> ><br>
>>> >> >> > They do:<br>
>>> >> >> ><br>
>>> >> >> > void func( int * __ptr32 p ) {}<br>
>>> >> >> > void func2( int * __ptr64 p ) {}<br>
>>> >> >> ><br>
>>> >> >> > PUBLIC ?func@@YAXPAH@Z ; func<br>
>>> >> >> > PUBLIC ?func2@@YAXPEAH@Z ; func2<br>
>>> >> >> ><br>
>>> >> >> > Namely, the presence of E (rnk pointed this out previously).<br>
>>> >> >> He was asking about __sptr and __uptr :). They don't by the way:<br>
>>> >> >><br>
>>> >> >> > cl /c test.cpp<br>
>>> >> >> [extraneous banner output omitted]<br>
>>> >> >> > dumpbin /symbols test.obj<br>
>>> >> >> [...]<br>
>>> >> >> 00F 00000010 SECT4 notype () External | ?func@@YAXPAH@Z<br>
>>> >> >> (void<br>
>>> >> >> __cdecl func(int *))<br>
>>> >> >> 010 00000020 SECT4 notype () External | ?func2@@YAXPAH@Z<br>
>>> >> >> (void<br>
>>> >> >> __cdecl func2(int *))<br>
>>> >> ><br>
>>> >> ><br>
>>> >> > Thanks. One more thing:<br>
>>> >> ><br>
>>> >> > template<typename T> void f(void **p, T *q) { *p = *q; }<br>
>>> >> ><br>
>>> >> > void *g(int *__ptr32 __sptr a) {<br>
>>> >> > void *result;<br>
>>> >> > f(&result, &a);<br>
>>> >> > return result;<br>
>>> >> > }<br>
>>> >> > void *h(char *__ptr32 __uptr a) {<br>
>>> >> > void *result;<br>
>>> >> > f(&result, &a);<br>
>>> >> > return result;<br>
>>> >> > }<br>
>>> >> ><br>
>>> >> > int main() {<br>
>>> >> > printf("%p\n", g((int *__ptr32 __sptr)0xdeadbeef));<br>
>>> >> > printf("%p\n", h((char *__ptr32 __uptr)0xdeadbeef));<br>
>>> >> > }<br>
>>> >> ><br>
>>> >> > Does one of these get sign-extended and the other one get<br>
>>> >> > zero-extended?<br>
>>> >><br>
>>> >> The first is sign extended, and the second is zero extended in 64-bit.<br>
>>> ><br>
>>> ><br>
>>> > What happens if you change the two 'char's to 'int's?<br>
>>><br>
>>> Both sign extend. Is that due to the template instantiation?<br>
>><br>
>><br>
>> Yeah, both are instantiated with canonically-equivalent arguments. That is<br>
>> madness, and we shouldn't support it unless we have a strong compatibility<br>
>> argument to do so.<br>
><br>
> I don't imagine that to be a problem.<br>
><br>
>> Can we get away with rejecting __uptr and ignoring<br>
>> __sptr?<br>
><br>
> In such an example, or on the whole? I don't think we can do it on<br>
> the whole because the purpose for this feature is to aid with WOW64<br>
> development and interop, and __uptr is really the only one of interest<br>
> (__sptr is the default behavior for conversion).<br>
><br>
> ~Aaron<br>
</div></div></blockquote></div><br>