================
@@ -7682,9 +7682,8 @@ PerformConstructorInitialization(Sema &S,
CurInit = S.CheckForImmediateInvocation(
CXXTemporaryObjectExpr::Create(
- S.Context, CalleeDecl,
- Entity.getType().getNonLValueExprType(S.Context), TSInfo,
- ConstructorArgs, ParenOrBraceRange, HadMultipleCandidates,
+ S.Context, CalleeDecl, Entity.getType().getNonReferenceType(),
+ TSInfo, ConstructorArgs, ParenOrBraceRange, HadMultipleCandidates,
----------------
tahonermann wrote:
Thank you, and sorry I missed that. This turned out to be really interesting.
[Section 3.3.4, "Member function qualifier" of the C++ for OpenCL
specification](https://www.khronos.org/opencl/assets/CXX_for_OpenCL.html#addrspace-member-function-qualifiers)
explicitly allows for member functions to have address space qualifiers. I
wasn't aware of this. Clang supports this, but only for the keyword forms of
the OpenCL address space qualifiers. See https://godbolt.org/z/cWfK9GjYc.
We aren't the first to discover this disparity. See
https://discourse.llvm.org/t/rfc-solution-for-preserving-the-address-space-of-this-in-c-methods/50526.
That discussion didn't reach a conclusion. Richard Smith suggested that
deducing this could eventually provide a solution for overloading based on the
address space of the implicit object and indeed that does work, but it requires
C++23. See https://godbolt.org/z/6excW14PP. (I couldn't test C++ for OpenCL in
this case because there does not appear to be a way to specify an alternate C++
standard version when compiling for C++ for OpenCL). I find myself agreeing
with Anastasia's conclusion; the method qualifiers approach is quite appealing.
Since we don't intend (so far) to provide keyword forms of the SYCL address
space attributes, I think this is something we should fix for consistency. But
not as part of this PR and probably not in the immediate future. If you agree,
I'll file a new issue to track doing that work.
I'd still like to think a bit about how address space qualifiers should apply
to temporary materialization.
While studying the history here, I came across a number of related open github
issues that indicate others have also wrestled with some of these concerns in
the past.
- https://github.com/llvm/llvm-project/issues/5162
- https://github.com/llvm/llvm-project/issues/198703
- https://github.com/llvm/llvm-project/issues/42641
https://github.com/llvm/llvm-project/pull/221233
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
