[llvm-bugs] [Bug 39674] New: [OpenCL C++] ICE on the nested pointer indirection with address space conversion in OpenCL C++ mode
via llvm-bugs
llvm-bugs at lists.llvm.org
Thu Nov 15 02:37:59 PST 2018
https://bugs.llvm.org/show_bug.cgi?id=39674
Bug ID: 39674
Summary: [OpenCL C++] ICE on the nested pointer indirection
with address space conversion in OpenCL C++ mode
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangbugs at nondot.org
Reporter: anastasia.stulova at arm.com
CC: anastasia.stulova at arm.com, llvm-bugs at lists.llvm.org
Multiple pointer indirection casting isn't working correctly. I.e. the
following program:
kernel void foo(){
__private int** loc;
int** loc_p = loc;
**loc_p = 1;
}
will fail with ICE in C++ mode, but for C it will generate:
bitcast i32* addrspace(4)* %0 to i32 addrspace(4)* addrspace(4)*
and then perform store over pointer in AS 4 (generic). We have now lost the
information that the original pointer was in private AS and that the adjustment
of AS segment has to be performed before accessing memory pointed by the
pointer. Based on the current specification of addrspacecast in
https://llvm.org/docs/LangRef.html#addrspacecast-to-instruction I am not very
clear whether it can be used for this case without any modifications or
clarifications and also what would happen if there are multiple AS mismatches.
C++'s rules assume that qualifiers don't introduce real representation
differences and that operations on qualified types are compatible with
operations on unqualified types. That's not true of qualifiers in general:
address space qualifiers can change representations, ARC qualifiers can have
incompatible semantics, etc. There is no way to soundly implement a conversion
from __private int ** to __generic int **, just there's no way to soundly
implement a conversion from Derived ** to Base **.
Following this logic it seems reasonable to just disallow such conversions in
order to prevent surprising behavior in the program.
See original discussion in https://reviews.llvm.org/D53764
--
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/20181115/ace83656/attachment-0001.html>
More information about the llvm-bugs
mailing list