[cfe-commits] [PATCH] [VCPP] Add __ptr64 qualifier

[Aaron Ballman]

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 <cdavis5x at gmail.com> 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
>