hfinkel added a comment. > Another option would be to implement some sort of attribute-based > overloading. Then OpenMP can provide its own version of the device-side > library function without clashing with system headers.
I'm thinking about what the desired behavior is here. So, if we have a situation where the target is the host, then we really only have one set of headers and we want everything to work as it does today. math.h should be math.h, with the same relevant preprocessor context. When the host and target differ, then we have a restricted set of external/system device functions available on the device (which may or may not have anything to do with the set of system functions provided by the host's system headers). 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? 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
