================
@@ -315,43 +315,53 @@ void
SemaSYCL::CheckSYCLEntryPointFunctionDecl(FunctionDecl *FD) {
}
}
+ if (isa<CXXConstructorDecl>(FD)) {
+ Diag(SKEPAttr->getLocation(), diag::err_sycl_entry_point_invalid)
+ << SKEPAttr << /*constructor*/ 3;
+ SKEPAttr->setInvalidAttr();
+ }
+ if (isa<CXXDestructorDecl>(FD)) {
+ Diag(SKEPAttr->getLocation(), diag::err_sycl_entry_point_invalid)
+ << SKEPAttr << /*destructor*/ 4;
+ SKEPAttr->setInvalidAttr();
+ }
if (const auto *MD = dyn_cast<CXXMethodDecl>(FD)) {
- if (!MD->isStatic()) {
+ if (MD->isExplicitObjectMemberFunction()) {
----------------
tahonermann wrote:
The motivation for allowing the `sycl_kernel_entry_point` attribute on
non-static member functions is solely so that the call to `sycl_kernel_launch`
will have a `this` pointer available. This allows the SYCL RT to store
per-invocation state in the enclosing class without having to resort to some
kind of (probably type unsafe) context pointer to be passed to
`sycl_kernel_launch`.
The support for non-static member functions prohibits (implicit or explicit)
use of `this` within the function body (except for in the implicit call to
`sycl_kernel_launch()`); see the diagnostic added to
`OutlinedFunctionDeclBodyInstantiator::TransformCXXThisExpr()` in
`clang/lib/Sema/SemaSYCL.cpp`. We could potentially do similarly for an
explicit object parameter, but the desired semantics aren't clear to me. `this`
is always a pointer and the pointed to object is never a kernel argument. An
explicit object type can be a non-reference/non-pointer type. In that case,
should it become a kernel argument? Should the implicit call to
`sycl_kernel_launch()` implicitly use the explicit object parameter? With no
use case or particular motivation for supporting explicit object parameters, I
felt the conservative thing to do is just prohibit their use. We can relax this
if motivation arises with clear semantics arises.
https://github.com/llvm/llvm-project/pull/152403
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
