hfinkel added a comment. In https://reviews.llvm.org/D50845#1202965, @Hahnfeld wrote:
> In https://reviews.llvm.org/D50845#1202963, @hfinkel wrote: > > > As a result, we should really have a separate header that has those > > actually-available functions. When targeting NVPTX, why don't we have the > > included math.h be CUDA's math.h? In the end, those are the functions we > > need to call when we generate code. Right? > > > That's what https://reviews.llvm.org/D47849 deals with. Yes, but it doesn't get CUDA's math.h. Maybe I misunderstand how this works (and I very well might, because it's not clear that CUDA has a math.h by that name), but that patch tries to avoid problems with the host's math.h and then also injects __clang_cuda_device_functions.h into the device compilation. How does this compare to when you include math.h in Clang's CUDA mode? It seems to be that we want to somehow map standard includes, where applicable, to include files in CUDA's include/crt directory (e.g., crt/math_functions.h and crt/common_functions.h for stdio.h for printf), and nothing else ends up being available (because it is, in fact, not available). Repository: rC Clang https://reviews.llvm.org/D50845 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
