On Tue, May 14, 2013 at 6:26 PM, Aaron Ballman <[email protected]> wrote: > On Tue, May 14, 2013 at 5:24 PM, Richard Smith <[email protected]> wrote: >> On Tue, May 14, 2013 at 2:02 PM, Aaron Ballman <[email protected]> >> wrote: >>> >>> On Tue, May 14, 2013 at 4:52 PM, Richard Smith <[email protected]> >>> 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. > > I don't see an issue with that; but this means we would have to shift > away from AttributedType for the qualifiers? > >> Do __sptr and __uptr get different manglings? > > They do: > > void func( int * __ptr32 p ) {} > void func2( int * __ptr64 p ) {} > > PUBLIC ?func@@YAXPAH@Z ; func > PUBLIC ?func2@@YAXPEAH@Z ; func2 > > Namely, the presence of E (rnk pointed this out previously). > >>> > 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); > > No, because T __ptr32 * isn't legal (the __ptr32 must follow the *). However: > > template<typename T> void f(T *__ptr32 p); > template void f<int*>(int *__ptr32 *p); > > yields a warning I can't say I've seen before: > > warning C4667: 'void f(int * __ptr32__ptr32 *)' : no function template > defined that matches forced instantiation
template<typename T> void f(T *__ptr32 p); template void f<int *>(int * * __ptr32 p); This, however, compiles without issue. ~Aaron _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
