[PATCH] D23627: [CUDA] Improve handling of math functions.

Artem Belevich via cfe-commits cfe-commits at lists.llvm.org
Wed Aug 17 15:21:16 PDT 2016


tra added inline comments.

================
Comment at: clang/lib/Headers/__clang_cuda_cmath.h:125-133
@@ -122,8 +124,11 @@
 __DEVICE__ float modf(float __x, float *__iptr) { return ::modff(__x, __iptr); }
-__DEVICE__ float nexttoward(float __from, float __to) {
+__DEVICE__ float nexttoward(float __from, double __to) {
   return __builtin_nexttowardf(__from, __to);
 }
 __DEVICE__ double nexttoward(double __from, double __to) {
   return __builtin_nexttoward(__from, __to);
 }
+__DEVICE__ float nexttowardf(float __from, double __to) {
+  return __builtin_nexttowardf(__from, __to);
+}
 __DEVICE__ float pow(float __base, float __exp) {
----------------
You've got two identical `nexttoward(float, double)` now.
Perhaps first one was supposed to remain `nexttoward(float, float)` ?



================
Comment at: clang/lib/Headers/__clang_cuda_cmath.h:184-197
@@ +183,16 @@
+
+// Defines an overload of __fn that accepts one two arithmetic arguments, calls
+// __fn((double)x, (double)y), and returns a double.
+//
+// Note this is different from OVERLOAD_1, which generates an overload that
+// accepts only *integral* arguments.
+#define __CUDA_CLANG_FN_INTEGER_OVERLOAD_2(__retty, __fn)                      \
+  template <typename __T1, typename __T2>                                      \
+  __DEVICE__ typename __clang_cuda_enable_if<                                  \
+      std::numeric_limits<__T1>::is_specialized &&                             \
+          std::numeric_limits<__T2>::is_specialized,                           \
+      __retty>::type                                                           \
+  __fn(__T1 __x, __T2 __y) {                                                   \
+    return __fn((double)__x, (double)__y);                                     \
+  }
+
----------------
`is_specialized` will be true for `long double` args and we'll instantiate the function. Can we/should we produce an error instead?


https://reviews.llvm.org/D23627





More information about the cfe-commits mailing list