Apologies, I stand corrected in two ways; you're right that we do need to distinguish for name mangling, and we need it for code generation as well it seems.
// Code int *p = 0x0; int * __ptr64 p2 = p; // Assembly ; 12 : int *p = 0x0; mov DWORD PTR _p$[ebp], 0 ; 13 : int * __ptr64 p2 = p; mov eax, DWORD PTR _p$[ebp] cdq mov DWORD PTR _p2$[ebp], eax mov DWORD PTR _p2$[ebp+4], edx So yes, we do need to track the type attribute fully in order to support it properly. Regardless, pravic's patch moves us in the right direction for mangling 64-bit native pointers (sans type attributes). It seems like we could accept that patch, possibly add a few XFAIL test cases for the __ptr32 and __ptr64 findings, and deal with the type attribute in the future. ~Aaron On Thu, Nov 8, 2012 at 6:19 PM, Charles Davis <[email protected]> wrote: > > On Nov 8, 2012, at 2:33 PM, Aaron Ballman wrote: > >> I finally had the chance to dig a bit deeper into this... >> >> I'm not certain we'd need to do anything aside from fix 64-bit >> mangling of pointers, truth be told. From looking at the >> documentation, it seems those type attributes are ignored on Windows. >> It doesn't appear that cl mangles them identically, regardless of >> target architecture (including ARM). > So which is it? Are they ignored or not? From the looks of it... >> >> Namely: >> // Code >> int * __ptr32 p32; >> int * __ptr64 p64; >> >> // Assembly >> PUBLIC ?p32@@3PAHA ; p32 >> PUBLIC ?p64@@3PEAHEA ; p64 >> >> Those mangled names are the same when I compile for x86, x64 and ARM, >> so empirical testing seems to agree with documented behavior from >> MSDN. > ...I'd say not, because their mangled names are clearly different. >> >> Basically, I think we can parse and eat __ptr64 and __ptr32, and >> simply mangle as proper for the native architecture and be fine. > But if a program uses explicit `__ptr32` or `__ptr64`, we won't be fine > because the names will get mangled wrong. This--this right here--is exactly > why I held off on implementing this. > > Chip > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
