<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 - Problem automatically deducing template parameters with address spaces in OpenCL"
href="https://bugs.llvm.org/show_bug.cgi?id=50162">50162</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Problem automatically deducing template parameters with address spaces in OpenCL
</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>drohr@jwdt.org
</td>
</tr>
<tr>
<th>CC</th>
<td>anastasia.stulova@arm.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=24810" name="attach_24810" title="testcase">attachment 24810</a> <a href="attachment.cgi?id=24810&action=edit" title="testcase">[details]</a></span>
testcase
I am not sure whether this is a real bug in the sense of the OpenCL
specification, it resembles a bit what was discussed here:
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Address space problem with automatic variables"
href="show_bug.cgi?id=42033">https://bugs.llvm.org/show_bug.cgi?id=42033</a>
My problem is that C++ for OpenCL fails to deduce the template parameters in
many cases, when address spaces get involved.
Note: the following test case requires <a href="https://reviews.llvm.org/D101168">https://reviews.llvm.org/D101168</a>.
I have been testing with clang trunk (clang version 13.0.0
(<a href="https://github.com/llvm/llvm-project.git">https://github.com/llvm/llvm-project.git</a>
837fded984ed36fa462daeb0f671eec58f71ae26)) + <a href="https://reviews.llvm.org/D101168">https://reviews.llvm.org/D101168</a>
and with the following command line:
/home/qon/alice/llvm-project/build/bin/clang++ -O0 -cl-std=clc++ -x cl
-emit-llvm --target=spir64-unknown-unknown -Xclang -fdenormal-fp-math-f32=ieee
-cl-mad-enable -cl-no-signed-zeros -ferror-limit=1000
-Dcl_clang_storage_class_specifiers -c fail.cl -o test.bc
The error I am getting is:
In file included from ../Base/opencl-common/GPUReconstructionOCL.cl:80:
In file included from ../Base/GPUReconstructionIncludesDevice.h:104:
../Refit/GPUTrackingRefit.cxx:101:7: error: no viable overloaded '='
trk = trkX;
~~~ ^ ~~~~
../Refit/GPUTrackingRefit.cxx:215:3: note: in instantiation of function
template specialization 'o2::gpu::GPUTrackingRefit::convertTrack<__private
o2::track::TrackParametrizationWithError<>, __generic
o2::gpu::GPUTPCGMMergedTrack, const __generic o2::base::PropagatorImpl<float>
*__private>' requested here
convertTrack(trk, trkX, prop, &TrackParCovChi2);
^
/home/qon/alice/O2/DataFormats/Reconstruction/include/ReconstructionDataFormats/TrackParametrizationWithError.h:50:48:
note: candidate function not viable: no known conversion from 'const __generic
o2::gpu::GPUTPCGMMergedTrack' to 'const __generic
o2::track::TrackParametrizationWithError<>' for 1st argument
TrackParametrizationWithError& operator=(const
TrackParametrizationWithError& src) = default;
^
/home/qon/alice/O2/DataFormats/Reconstruction/include/ReconstructionDataFormats/TrackParametrizationWithError.h:51:48:
note: candidate function not viable: no known conversion from 'const __generic
o2::gpu::GPUTPCGMMergedTrack' to '__generic
o2::track::TrackParametrizationWithError<>' for 1st argument
TrackParametrizationWithError&
operator=(TrackParametrizationWithError&& src) = default;
^
In file included from ../Base/opencl-common/GPUReconstructionOCL.cl:80:
In file included from ../Base/GPUReconstructionIncludesDevice.h:104:
I think the problem is that it deduces the template parameters as "__generic
TYPE&" etc, and that will not work in all cases, particular if references to
non generic variables are passed in. But then, if I explicitly state the
template parameters, as I do in workaround.patch, it works. What I am doing is
just ommiting the address space completely, so it will now work with all of
them (except __constant).
Another workaround is to define the template function in the way
template <class T> void foo(__generic T& bar) ...
but that has the problem that now it only works with the __generic address
space, so it breaks when one passes in local variables.
Overall, this situation makes templates with references / pointers pretty much
unusable. There are workarounds in our code all over the place, so I am
wondering whether one could improve the situation in general. I think the
problem is that the address space is part of the template type. Not sure what
could be a proper solution, but frankly I do not understand why the address
space must become a part of the template type at all, why cannot this be
stripped?</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>