Here is an updated patch that is meant to handle the semantics up to (but not including) codegen, including test cases.
~Aaron On Tue, May 14, 2013 at 8:54 PM, Aaron Ballman <[email protected]> wrote: > On Tue, May 14, 2013 at 8:50 PM, Richard Smith <[email protected]> wrote: >> On Tue, May 14, 2013 at 5:47 PM, Aaron Ballman <[email protected]> >> wrote: >>> >>> On Tue, May 14, 2013 at 8:42 PM, Richard Smith <[email protected]> >>> wrote: >>> > On Tue, May 14, 2013 at 5:41 PM, Aaron Ballman <[email protected]> >>> > wrote: >>> >> >>> >> On Tue, May 14, 2013 at 8:34 PM, Richard Smith <[email protected]> >>> >> wrote: >>> >> > On Tue, May 14, 2013 at 4:07 PM, Charles Davis <[email protected]> >>> >> > wrote: >>> >> >> >>> >> >> >>> >> >> On May 14, 2013, at 4:26 PM, Aaron Ballman wrote: >>> >> >> > >>> >> >> >> 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). >>> >> >> He was asking about __sptr and __uptr :). They don't by the way: >>> >> >> >>> >> >> > cl /c test.cpp >>> >> >> [extraneous banner output omitted] >>> >> >> > dumpbin /symbols test.obj >>> >> >> [...] >>> >> >> 00F 00000010 SECT4 notype () External | ?func@@YAXPAH@Z >>> >> >> (void >>> >> >> __cdecl func(int *)) >>> >> >> 010 00000020 SECT4 notype () External | ?func2@@YAXPAH@Z >>> >> >> (void >>> >> >> __cdecl func2(int *)) >>> >> > >>> >> > >>> >> > Thanks. One more thing: >>> >> > >>> >> > template<typename T> void f(void **p, T *q) { *p = *q; } >>> >> > >>> >> > void *g(int *__ptr32 __sptr a) { >>> >> > void *result; >>> >> > f(&result, &a); >>> >> > return result; >>> >> > } >>> >> > void *h(char *__ptr32 __uptr a) { >>> >> > void *result; >>> >> > f(&result, &a); >>> >> > return result; >>> >> > } >>> >> > >>> >> > int main() { >>> >> > printf("%p\n", g((int *__ptr32 __sptr)0xdeadbeef)); >>> >> > printf("%p\n", h((char *__ptr32 __uptr)0xdeadbeef)); >>> >> > } >>> >> > >>> >> > Does one of these get sign-extended and the other one get >>> >> > zero-extended? >>> >> >>> >> The first is sign extended, and the second is zero extended in 64-bit. >>> > >>> > >>> > What happens if you change the two 'char's to 'int's? >>> >>> Both sign extend. Is that due to the template instantiation? >> >> >> Yeah, both are instantiated with canonically-equivalent arguments. That is >> madness, and we shouldn't support it unless we have a strong compatibility >> argument to do so. > > I don't imagine that to be a problem. > >> Can we get away with rejecting __uptr and ignoring >> __sptr? > > In such an example, or on the whole? I don't think we can do it on > the whole because the purpose for this feature is to aid with WOW64 > development and interop, and __uptr is really the only one of interest > (__sptr is the default behavior for conversion). > > ~Aaron
sptr_uptr.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
