https://bugs.llvm.org/show_bug.cgi?id=42359
Bug ID: 42359
Summary: [MS] Implement full support for __ptr32, __ptr64,
__sptr, __uptr
Product: clang
Version: 8.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: akhuang at google.com
Reporter: rnk at google.com
CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
richard-llvm at metafoo.co.uk
Clang parses these qualifiers as attributes, but they don't have any semantic
meaning. A Chromium developer used a Windows typedef that happened to have one
of these qualifiers and ran into issues with it: https://crbug.com/972185
Clang should implement these qualifiers, since we accept them without warning.
Consider this program:
typedef void *__ptr32 PVOID;
template <typename T> struct Foo { static_assert(sizeof(T) == 4, "asdf"); };
template struct Foo<PVOID>;
void *getp2(PVOID p) {
static_assert(sizeof(p) == 4, "asdf");
return *p;
}
Today we retain __ptr32 as sugar, like this:
|-TypedefDecl 0x1b842c987c0 <t.cpp:1:1, col:23> col:23 referenced PVOID 'void *
__ptr32':'void *'
| `-AttributedType 0x1b842c98770 'void * __ptr32' sugar
| |-PointerType 0x1b842c98180 'void *'
| | `-BuiltinType 0x1b842c97980 'void'
| `-PointerType 0x1b842c98180 'void *'
| `-BuiltinType 0x1b842c97980 'void'
We need to change the canonical type of PVOID to be something other than
'void*', so that the static_asserts pass inside and outside of the template. I
think we could implement this as an address space qualifier on the pointee type
of the pointer, or we could add some other kind of qualifiers.
I believe the qualifiers are ignored if the pointer size matches the default
for the current compilation mode, so Foo<void*> and Foo<void*__ptr64> are the
same in x64. I wonder how the __sptr / __uptr qualifiers are treated.
For codegen, we have to truncate, sign extend, or zero extend when converting
between different kinds of pointers, depending on the __sptr / __uptr
qualifier. I think this roughly corresponds to userspace address, or kernel
address.
I think it makes sense to lower these down to i32 and i64 types as appropriate,
since we need to load and store them and use sign and zero extension on them.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190621/0f67888a/attachment.html>