================
@@ -14794,9 +14803,36 @@ void
ASTContext::getFunctionFeatureMap(llvm::StringMap<bool> &FeatureMap,
}
}
-static SYCLKernelInfo BuildSYCLKernelInfo(CanQualType KernelNameType,
+static SYCLKernelInfo BuildSYCLKernelInfo(ASTContext &Context,
+ CanQualType KernelNameType,
const FunctionDecl *FD) {
- return {KernelNameType, FD};
+ // Host and device compilation may use different ABIs and different ABIs
+ // may allocate name mangling discriminators differently. A discriminator
+ // override is used to ensure consistent discriminator allocation across
+ // host and device compilation.
+ auto DeviceDiscriminatorOverrider =
+ [](ASTContext &Ctx, const NamedDecl *ND) -> std::optional<unsigned> {
+ if (const auto *RD = dyn_cast<CXXRecordDecl>(ND))
+ if (RD->isLambda())
----------------
erichkeane wrote:
My concern here is: What happens if a `genericLambda` gets here, which I
believe will have an unset 'mangling-id'. I'd VERY much like to not let this
get pushed to the next one, in part since the ways forward aren't a
particularly sizable amount of work.
I see a few ways forward:
1- Create an example that shows the mangler properly handling the
generic-lambda. Note you might have to do some work to get here, as getting
generic-lambdas mangled often requires some surprising things to make happen.
2- Prove in some-way that generic-lambda cannot get here (which, would actually
take quite a bit of convincing, dependent types find their way to sneak into
the mangler all the time unfortunately, particularly with SFINAE and
`diagnose_if`/etc).
2- 'assert(!isGenericLambda() && "dont' know how to handle generic lambdas
yet");`
https://github.com/llvm/llvm-project/pull/133030
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
