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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
