tra added inline comments.
================ Comment at: clang/lib/Sema/SemaLambda.cpp:1783 + + if (LangOpts.CUDA && LangOpts.CUDAIsDevice) + CUDACheckLambdaCapture(CallOperator, From); ---------------- yaxunl wrote: > tra wrote: > > I would expect Sema-level diags to be produced during both host and device > > compilation. Some of the diags for HD may need to be postponed until after > > things have been CodeGen'ed, but the checks should happen nevertheless. > > > > > A host device function could be emitted in both host and device compilation. > The way the deferred diags works is that they are only emitted when the > function is sure to be emitted in a specific compilation. In host > compilation, when a host device function is sure to be emitted, it is emitted > as host function, therefore diags for host compilation and only diags for > host compilation should be emitted. The same with device compilation. > > This makes sense since we do not know if a host device function will be > emitted in device compilation when we are doing host compilation, since to do > that we have to go through the whole device compilation whereas currently > device compilation and host compilation are separate process. > > That said, when we emit diags for captures by reference, we should only emit > them when the lambdas are emitted as device functions. When they are emitted > as host functions in host compilation, these captures are valid and should > not be diagnosed. HD lambda capturing something that's side-specific is similar to HD function calling side-specific function. I still think that the general principle applies to both sides of the compilation. We may be saved by the fact that functions seem to be the only things that are truly side-specific and wrong-side access will already produce postponed diagnostics. For variables we'll end up capturing shadows, which is in the gray area -- we're allowed to use pointers & sizeof(), but not the non-const values. Perhaps this condition check should be folded into the `CUDACheckLambdaCapture` and add few comments about the reasons for particular OK/not-OK choices we make there. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78655/new/ https://reviews.llvm.org/D78655 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
