yaxunl added a comment. In D104505#2833746 <https://reviews.llvm.org/D104505#2833746>, @tra wrote:
> In D104505#2833271 <https://reviews.llvm.org/D104505#2833271>, @yaxunl wrote: > >> Such host/device overloading resolution induced issue is not limited to >> device functions calling host functions. > > It does not change the fact that the code in the test above is invalid, > regardless of whether we compile it on the host or on the device. > >> It could also happen to host device functions calling host functions, which >> is less controversial for deferring. > > H/D functions are special, because their overloading is affected whether > compilation is done on the host or on the device side and we often can not > tell whether the diagnostic is appropriate until codegen. > > I still think that deferring diags for unambiguously invalid code is not a > good idea. The fact that NVCC can only diagnose such errors during > device-side compilation is not a good enough reason, IMO, to make clang > ignore real errors, even if we'd still end up eventually failing later, > during device-side compilation. > > @rsmith, @rjmccall -- any thoughts? We don't defer such diags by default. We only defer them under option -fgpu-defer-diags, which users have to specify explicitly. 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
