[cfe-dev] Mixed 32b/64b pointers in same translation unit

[Friedman, Eli via cfe-dev]

On 2/2/2017 10:00 AM, Patrik Eklöf via cfe-dev wrote:
>
> Thanks for the answer, Reid.
>
> I tried your suggestion and it worked on simpler types where I 
> initialize pointers to some constant value, e.g.
>
> constexpr __attribute__((address_space(0))) int* HiIAmA64BitPtr{ 
> nullptr };
>
> constexpr __attribute__((address_space(4))) int* HiIAmA32BitPtr{ 
> nullptr };
>
> int main()
>
> {
>
> static_assert(sizeof(HiIAmA32BitPtr) == 4);
>
> static_assert(sizeof(HiIAmA64BitPtr) == 8);
>
> }
>
> But when I tried something more complex, it stops working. For example:
>
> void foo() {}
>
> __attribute((address_space(4))) void bar() {}
>
> constexpr __attribute__((address_space(0))) auto* HiIAmA64BitPtr{ &foo };
>
> constexpr __attribute__((address_space(4))) auto* HiIAmA32BitPtr{ &bar };
>
> int main()
>
> {
>
> constexpr auto SizeOf32 = sizeof(HiIAmA32BitPtr);
>
> constexpr auto SizeOf64 = sizeof(HiIAmA64BitPtr);
>
> static_assert(sizeof(HiIAmA32BitPtr) == 4);
>
> static_assert(sizeof(HiIAmA64BitPtr) == 8);
>
> }
>
> From what I can gather, it tries to take the address space of the 
> parent type (or the dereferenced type of a pointer). My guess is that 
> in the former experiment, the attribute binds to the dereferenced type 
> and not the pointer? In this case, it doesn’t seem to work, though. 
> Presumably because the attribute binds to the pointer type? I’m not 
> sure. Regardless, it doesn’t work, and I’m still not sure why.
>
> The assert that the 32-bit pointer is 4 bytes fails.
>
> Any ideas?
>
>

clang doesn't currently support address spaces on function pointers.  
You're getting a weird result because the address space is getting 
attached to the return type; clang should reject that, but currently 
doesn't.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170202/f0439acb/attachment.html>