[Bug 241550] Base Clang can't compile trivial CUDA programs: error: no matching function for call to '__isnan'

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Tue Oct 29 19:27:02 UTC 2019


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241550

Dimitry Andric <dim at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |antoine at FreeBSD.org

--- Comment #4 from Dimitry Andric <dim at FreeBSD.org> ---
Hm even looking at the tree in the state of just before base r253215, I see
only three instances of __isnan:

lib/libc/gen/isnan.c: __weak_reference(__isnan, isnan);
lib/libc/gen/isnan.c: __isnan(double d)
lib/libc/gen/Symbol.map:        __isnan;

I'm now testing a universe build with this diff:

Index: lib/msun/src/math.h
===================================================================
--- lib/msun/src/math.h (revision 354146)
+++ lib/msun/src/math.h (working copy)
@@ -111,7 +111,7 @@ extern const union __nan_un {
 #define        isfinite(x) __fp_type_select(x, __isfinitef, __isfinite,
__isfinitel)
 #define        isinf(x) __fp_type_select(x, __isinff, __isinf, __isinfl)
 #define        isnan(x) \
-       __fp_type_select(x, __inline_isnanf, __inline_isnan, __inline_isnanl)
+       __fp_type_select(x, __isnanf, __isnan, __isnanl)
 #define        isnormal(x) __fp_type_select(x, __isnormalf, __isnormal,
__isnormall)

 #ifdef __MATH_BUILTIN_RELOPS
@@ -194,7 +194,7 @@ int __signbitf(float) __pure2;
 int    __signbitl(long double) __pure2;

 static __inline int
-__inline_isnan(__const double __x)
+__isnan(__const double __x)
 {

        return (__x != __x);
@@ -201,7 +201,7 @@ static __inline int
 }

 static __inline int
-__inline_isnanf(__const float __x)
+__isnanf(__const float __x)
 {

        return (__x != __x);
@@ -208,7 +208,7 @@ static __inline int
 }

 static __inline int
-__inline_isnanl(__const long double __x)
+__isnanl(__const long double __x)
 {

        return (__x != __x);


If that goes well, maybe it's best to do an exp-run too?  It's more likely that
some ports fall over due to this change, than anything in our base system...

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-toolchain mailing list