yaxunl added a comment. In D104505#2831811 <https://reviews.llvm.org/D104505#2831811>, @tra wrote:
> In D104505#2831644 <https://reviews.llvm.org/D104505#2831644>, @yaxunl wrote: > >> However, this does cause source level incompatibilities, i.e. CUDA code that >> passes nvcc does not pass clang. This patch somehow addresses that without >> compromising clang's more sophisticated `__host__/__device__` overloading >> resolution capabilities. > > Yes. This will not be the first time where clang does diagnose invalid code > while NVCC does not. > In general, some amount of source code porting between nvcc and clang is > expected. In practice the amount of work required to make CUDA code portable > has been relatively minor. > > My general rule of thumb is that if both host and device compilation have > enough information to diagnose a problem, both should do it. > In this case, there's no ambiguity that the code is invalid. The sooner we > diagnose it, the better. > > Is there particular use case where this patch would be necessary? Such host/device overloading resolution induced issue is not limited to device functions calling host functions. It could also happen to host device functions calling host functions, which is less controversial for deferring. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D104505/new/ https://reviews.llvm.org/D104505 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
