================
@@ -14296,6 +14296,31 @@ void
ASTContext::getFunctionFeatureMap(llvm::StringMap<bool> &FeatureMap,
}
}
+static SYCLKernelInfo BuildSYCLKernelInfo(ASTContext &Context,
+ CanQualType KernelNameType,
+ const FunctionDecl *FD) {
+ return { KernelNameType, FD };
+}
+
+void ASTContext::registerSYCLEntryPointFunction(FunctionDecl *FD) {
+ assert(!FD->isInvalidDecl());
+ assert(!FD->isDependentContext());
+
+ const auto *SKEPAttr = FD->getAttr<SYCLKernelEntryPointAttr>();
+ assert(SKEPAttr && "Missing sycl_kernel_entry_point attribute");
+
+ CanQualType KernelNameType = getCanonicalType(SKEPAttr->getKernelName());
+ auto IT = SYCLKernels.find(KernelNameType);
+ if (IT != SYCLKernels.end()) {
+ if (!declaresSameEntity(FD, IT->second.GetKernelEntryPointDecl()))
+ llvm::report_fatal_error("SYCL kernel name conflict");
----------------
tahonermann wrote:
I pushed changes to replace the call to `llvm::report_fatal_error()` with
`assert()` following discussion with other colleagues. I still disagree with
this direction. As a user, I would much prefer that the compiler fail
catastrophically than continue merrily along generating a binary that doesn't
behave as expected (In these days of safety consciousness, we would really
rather continue into UB land than abort? Really?) . I acknowledge such
eventualities will only occur if we fail to properly diagnose elsewhere, so the
stakes are hopefully not so high. Still, I reserve the right to be unhappy and
say, "I told you so" while vigorously wagging a finger if we end up getting a
bug report detailing someone's difficult experience debugging why their
application was mysteriously invoking the wrong SYCL kernel. I'm now resolving
this conversation.
https://github.com/llvm/llvm-project/pull/111389
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
