[PATCH] Initial support for __sptr and __uptr

Richard Smith richard at metafoo.co.uk
Tue May 14 14:24:23 PDT 2013


On Tue, May 14, 2013 at 2:02 PM, Aaron Ballman <aaron at aaronballman.com>wrote:

> On Tue, May 14, 2013 at 4:52 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > Yes, this looks like the direction I was suggesting, but I feel a little
> > uneasy about this -- it seems deeply weird for these attributes to not
> > affect the canonical type. To what extent do we need to support them (is
> > parse-but-ignore enough)? Is sizeof(int *__ptr32) 4 even on a 64-bit
> system,
> > and is sizeof(int *__ptr64) 8 even on a 32-bit system?
>
> int * __ptr32 p32 = 0;
> int * __ptr64 p64 = 0;
>
> ::printf( "%d, %d", sizeof( p32 ), sizeof( p64 ) );
>
> 32-bit platform: 4, 8
> 64-bit platform: 4, 8
>
> My plan was to get parse-but-ignore in place, and then begin to
> evaluate the codegen side of things.


OK, we will (in the big blue eventually) need for these types to be
canonically different, then. That would also mean that we would be able to
overload on __ptr32/__ptr64-ness, but I don't think that's really a problem.

Do __sptr and __uptr get different manglings?


> > Also, do we actually want to have the functionality in
> > distributeMSTypeAttrFromDeclarator? Can these keywords go after the
> > declarator-id (eg int *p __sptr;)? Even if so, presumably you didn't
> mean to
> > allow "int *X::*p __ptr32 __sptr"?
>
> That's a good point, they're only legal between the pointer and the
> identifier (if any) in a declaration.  So the distribute function is
> unneeded.
>
> Are there other areas I am forgetting to touch for this (aside from
> the obvious codegen and lower parts)?


Since you're just representing this as type sugar with no semantic impact,
I don't think there's anything else you need to change just yet. Once these
attributes start having a semantic impact, there will be other places
(implicit conversions, casts, initialization, overload resolution, possibly
template argument deduction) that will need updates.

Another thought: does MSVC allow this kind of shenanigans:

template<typename T> void f(T __ptr32 *p);
template void f<int*>(int *__ptr32 *p);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130514/c7d15b13/attachment.html>


More information about the cfe-commits mailing list