<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - [OpenCL C++] ICE on the nested pointer indirection with address space conversion in OpenCL C++ mode"
href="https://bugs.llvm.org/show_bug.cgi?id=39674">39674</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[OpenCL C++] ICE on the nested pointer indirection with address space conversion in OpenCL C++ mode
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>OpenCL
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>anastasia.stulova@arm.com
</td>
</tr>
<tr>
<th>CC</th>
<td>anastasia.stulova@arm.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>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
<a href="https://llvm.org/docs/LangRef.html#addrspacecast-to-instruction">https://llvm.org/docs/LangRef.html#addrspacecast-to-instruction</a> 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 <a href="https://reviews.llvm.org/D53764">https://reviews.llvm.org/D53764</a></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>