[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