[PATCH] Initial support for __sptr and __uptr

[Reid Kleckner]

On Mon, May 13, 2013 at 9:08 PM, Aaron Ballman <aaron at aaronballman.com>wrote:

> On Mon, May 13, 2013 at 9:05 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > On Mon, May 13, 2013 at 5:59 PM, Aaron Ballman <aaron at aaronballman.com>
> > wrote:
> >>
> >> On Mon, May 13, 2013 at 8:51 PM, Richard Smith <richard at metafoo.co.uk>
> >> wrote:
> >> > You have ''__foo'' in some of your diagnostics. These should only use
> a
> >> > single level of quotes.
> >>
> >> The quotes were used for consistency with other diagnostics involving
> >> attributes.  I'll look into it again though.
> >>
> >> > Should these really be handled as declaration attributes? They look
> like
> >> > they would more naturally be type attributes. Can you do this:
> >> >
> >> >   void * __sptr * __uptr p;
> >>
> >> I think eventually they (along with __ptr32 and __ptr64) will have to
> >> move over to ExtQuals (or somewhere near there) because they're really
> >> type qualifers more than declaration attributes.  But I was modeling
> >> after existing constructs.  And yes, you can do that, though it's
> >> basically pointless because there's not a __ptrXX involved.  But you
> >> are correct, this really highlights that __ptrXX and __sptr/__uptr
> >> need to move to types instead of declarations.
> >>
> >> Do you think ExtQuals would be an appropriate place, or do you have a
> >> better suggestion?
> >
> >
> > ExtQuals (or rather, Qualifiers) does not have any spare bits. Do these
> > qualifiers affect the canonical type? That is, can you overload on this?
> > Does MSVC accept this:
> >
> > void f(int * __uptr __ptr32 * p) {}
> > void f(int * __sptr __ptr32 * p) {}
>
> You cannot -- same with __ptr32 vs __ptr64


Huh.  I would've expected that to work since they bothered to have a
separate mangling for ptr64.  But I see the same behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130514/3f893077/attachment.html>