[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL287012: [CUDA] Mark __libcpp_{isnan,isinf,isfinite} as 
constexpr. (authored by jlebar).

Changed prior to commit:
  https://reviews.llvm.org/D25403?vs=77271=78041#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D25403

Files:
  libcxx/trunk/include/cmath
  libcxx/trunk/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp


Index: libcxx/trunk/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
===
--- libcxx/trunk/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
+++ libcxx/trunk/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
@@ -0,0 +1,29 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// Check that the overloads of std::__libcpp_{isnan,isinf,isfinite} that take
+// floating-point values are evaluatable from constexpr contexts.
+//
+// These functions need to be constexpr in order to be called from CUDA, see
+// https://reviews.llvm.org/D25403.  They don't actually need to be
+// constexpr-evaluatable, but that's what we check here, since we can't check
+// true constexpr-ness.
+//
+// UNSUPPORTED: c++98, c++03
+
+#include 
+
+constexpr bool a = std::__libcpp_isnan(0.);
+constexpr bool b = std::__libcpp_isinf(0.0);
+constexpr bool c = std::__libcpp_isfinite(0.0);
+
+int main()
+{
+  return 0;
+}
Index: libcxx/trunk/include/cmath
===
--- libcxx/trunk/include/cmath
+++ libcxx/trunk/include/cmath
@@ -554,7 +554,7 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isnan(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isnan)
@@ -566,15 +566,15 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, 
bool>::type
 __libcpp_isnan(_A1 __lcpp_x) _NOEXCEPT
 {
 return isnan(__lcpp_x);
 }
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isinf(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isinf)
@@ -586,15 +586,15 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, 
bool>::type
 __libcpp_isinf(_A1 __lcpp_x) _NOEXCEPT
 {
 return isinf(__lcpp_x);
 }
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isfinite(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isfinite)
@@ -606,7 +606,7 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, 
bool>::type
 __libcpp_isfinite(_A1 __lcpp_x) _NOEXCEPT
 {
 return isfinite(__lcpp_x);


Index: libcxx/trunk/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
===
--- libcxx/trunk/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
+++ libcxx/trunk/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
@@ -0,0 +1,29 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// Check that the overloads of std::__libcpp_{isnan,isinf,isfinite} that take
+// floating-point values are evaluatable from constexpr contexts.
+//
+// These functions need to be constexpr in order to be called from CUDA, see
+// https://reviews.llvm.org/D25403.  They don't actually need to be
+// constexpr-evaluatable, but that's what we check here, since we can't check
+// true constexpr-ness.
+//
+// UNSUPPORTED: c++98, c++03
+
+#include 
+
+constexpr bool a = std::__libcpp_isnan(0.);
+constexpr bool b = std::__libcpp_isinf(0.0);
+constexpr bool c = std::__libcpp_isfinite(0.0);
+
+int main()
+{
+  return 0;
+}
Index: libcxx/trunk/include/cmath
===
--- libcxx/trunk/include/cmath
+++ libcxx/trunk/include/cmath
@@ -554,7 +554,7 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename 

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Eric Fiselier via cfe-commits]

EricWF added inline comments.



Comment at: libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp:17
+// true constexpr-ness.
+
+#include 

jlebar wrote:
> EricWF wrote:
> > Does GCC offer these as contexpr? If not this needs a `// XFAIL: gcc`
> Looks like the relevant builtins in gcc are constexpr-evaluatable: 
> https://godbolt.org/g/GcwJba
Also instead of using `TEST_STD_VER` you can write `// UNSUPPORTED: c++98, 
c++03`.


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Eric Fiselier via cfe-commits]

EricWF added inline comments.



Comment at: libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp:22
+
+#ifndef _LIBCPP_VERSION
+#error _LIBCPP_VERSION not defined

jlebar wrote:
> EricWF wrote:
> > You don't need this `_LIBCPP_VERSION` check here.
> Hm, there are lots of tests that have this, and since this test will not 
> compile with libstdc++, if it's not appropriate here, I am confused as to 
> when we should and shouldn't have this check.  When should it be used?
Every header has a test that including it provides `_LIBCPP_VERSION`, but 
that's the only time this needs to appear.


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar added a comment.

Thanks for the review.




Comment at: libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp:17
+// true constexpr-ness.
+
+#include 

EricWF wrote:
> Does GCC offer these as contexpr? If not this needs a `// XFAIL: gcc`
Looks like the relevant builtins in gcc are constexpr-evaluatable: 
https://godbolt.org/g/GcwJba



Comment at: libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp:22
+
+#ifndef _LIBCPP_VERSION
+#error _LIBCPP_VERSION not defined

EricWF wrote:
> You don't need this `_LIBCPP_VERSION` check here.
Hm, there are lots of tests that have this, and since this test will not 
compile with libstdc++, if it's not appropriate here, I am confused as to when 
we should and shouldn't have this check.  When should it be used?


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Eric Fiselier via cfe-commits]

EricWF accepted this revision.
EricWF added inline comments.
This revision is now accepted and ready to land.



Comment at: libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp:17
+// true constexpr-ness.
+
+#include 

Does GCC offer these as contexpr? If not this needs a `// XFAIL: gcc`



Comment at: libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp:22
+
+#ifndef _LIBCPP_VERSION
+#error _LIBCPP_VERSION not defined

You don't need this `_LIBCPP_VERSION` check here.


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Hal Finkel via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D25403#590049, @jlebar wrote:

> Use TEST_STD_VER macro.


This is fine with me; @EricWF , @mclow.lists ?


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar updated this revision to Diff 77271.
jlebar added a comment.

Use TEST_STD_VER macro.


https://reviews.llvm.org/D25403

Files:
  libcxx/include/cmath
  libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp


Index: libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
===
--- /dev/null
+++ libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
@@ -0,0 +1,35 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// Check that the overloads of std::__libcpp_{isnan,isinf,isfinite} that take
+// floating-point values are evaluatable from constexpr contexts.
+//
+// These functions need to be constexpr in order to be called from CUDA, see
+// https://reviews.llvm.org/D25403.  They don't actually need to be
+// constexpr-evaluatable, but that's what we check here, since we can't check
+// true constexpr-ness.
+
+#include 
+
+#include "test_macros.h"
+
+#ifndef _LIBCPP_VERSION
+#error _LIBCPP_VERSION not defined
+#endif
+
+#if TEST_STD_VER >= 11
+constexpr bool a = std::__libcpp_isnan(0.);
+constexpr bool b = std::__libcpp_isinf(0.0);
+constexpr bool c = std::__libcpp_isfinite(0.0);
+#endif
+
+int main()
+{
+  return 0;
+}
Index: libcxx/include/cmath
===
--- libcxx/include/cmath
+++ libcxx/include/cmath
@@ -560,7 +560,7 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isnan(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isnan)
@@ -572,15 +572,15 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, 
bool>::type
 __libcpp_isnan(_A1 __lcpp_x) _NOEXCEPT
 {
 return isnan(__lcpp_x);
 }
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isinf(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isinf)
@@ -592,15 +592,15 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, 
bool>::type
 __libcpp_isinf(_A1 __lcpp_x) _NOEXCEPT
 {
 return isinf(__lcpp_x);
 }
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isfinite(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isfinite)
@@ -612,7 +612,7 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, 
bool>::type
 __libcpp_isfinite(_A1 __lcpp_x) _NOEXCEPT
 {
 return isfinite(__lcpp_x);


Index: libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
===
--- /dev/null
+++ libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
@@ -0,0 +1,35 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// Check that the overloads of std::__libcpp_{isnan,isinf,isfinite} that take
+// floating-point values are evaluatable from constexpr contexts.
+//
+// These functions need to be constexpr in order to be called from CUDA, see
+// https://reviews.llvm.org/D25403.  They don't actually need to be
+// constexpr-evaluatable, but that's what we check here, since we can't check
+// true constexpr-ness.
+
+#include 
+
+#include "test_macros.h"
+
+#ifndef _LIBCPP_VERSION
+#error _LIBCPP_VERSION not defined
+#endif
+
+#if TEST_STD_VER >= 11
+constexpr bool a = std::__libcpp_isnan(0.);
+constexpr bool b = std::__libcpp_isinf(0.0);
+constexpr bool c = std::__libcpp_isfinite(0.0);
+#endif
+
+int main()
+{
+  return 0;
+}
Index: libcxx/include/cmath
===
--- libcxx/include/cmath
+++ libcxx/include/cmath
@@ -560,7 +560,7 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isnan(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isnan)
@@ -572,15 +572,15 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename 

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Hal Finkel via cfe-commits]

hfinkel added inline comments.



Comment at: libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp:24
+
+#if __cplusplus >= 201103L
+constexpr bool a = std::__libcpp_isnan(0.);

I think the preferred form here is:

#if TEST_STD_VER >= 11


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar updated this revision to Diff 77105.
jlebar added a comment.

Add a test.


https://reviews.llvm.org/D25403

Files:
  libcxx/include/cmath
  libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp


Index: libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
===
--- /dev/null
+++ libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
@@ -0,0 +1,33 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// Check that the overloads of std::__libcpp_{isnan,isinf,isfinite} that take
+// floating-point values are evaluatable from constexpr contexts.
+//
+// These functions need to be constexpr in order to be called from CUDA, see
+// https://reviews.llvm.org/D25403.  They don't actually need to be
+// constexpr-evaluatable, but that's what we check here, since we can't check
+// true constexpr-ness.
+
+#include 
+
+#ifndef _LIBCPP_VERSION
+#error _LIBCPP_VERSION not defined
+#endif
+
+#if __cplusplus >= 201103L
+constexpr bool a = std::__libcpp_isnan(0.);
+constexpr bool b = std::__libcpp_isinf(0.0);
+constexpr bool c = std::__libcpp_isfinite(0.0);
+#endif
+
+int main()
+{
+  return 0;
+}
Index: libcxx/include/cmath
===
--- libcxx/include/cmath
+++ libcxx/include/cmath
@@ -560,7 +560,7 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isnan(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isnan)
@@ -572,15 +572,15 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, 
bool>::type
 __libcpp_isnan(_A1 __lcpp_x) _NOEXCEPT
 {
 return isnan(__lcpp_x);
 }
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isinf(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isinf)
@@ -592,15 +592,15 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, 
bool>::type
 __libcpp_isinf(_A1 __lcpp_x) _NOEXCEPT
 {
 return isinf(__lcpp_x);
 }
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isfinite(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isfinite)
@@ -612,7 +612,7 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, 
bool>::type
 __libcpp_isfinite(_A1 __lcpp_x) _NOEXCEPT
 {
 return isfinite(__lcpp_x);


Index: libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
===
--- /dev/null
+++ libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
@@ -0,0 +1,33 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// Check that the overloads of std::__libcpp_{isnan,isinf,isfinite} that take
+// floating-point values are evaluatable from constexpr contexts.
+//
+// These functions need to be constexpr in order to be called from CUDA, see
+// https://reviews.llvm.org/D25403.  They don't actually need to be
+// constexpr-evaluatable, but that's what we check here, since we can't check
+// true constexpr-ness.
+
+#include 
+
+#ifndef _LIBCPP_VERSION
+#error _LIBCPP_VERSION not defined
+#endif
+
+#if __cplusplus >= 201103L
+constexpr bool a = std::__libcpp_isnan(0.);
+constexpr bool b = std::__libcpp_isinf(0.0);
+constexpr bool c = std::__libcpp_isfinite(0.0);
+#endif
+
+int main()
+{
+  return 0;
+}
Index: libcxx/include/cmath
===
--- libcxx/include/cmath
+++ libcxx/include/cmath
@@ -560,7 +560,7 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isnan(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isnan)
@@ -572,15 +572,15 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename 

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar added a comment.

Hal, whadya think?


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar added a comment.

So, good news -- these three builtins are already constexpr-evaluatable.  :)

I'll add a test.


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Hal Finkel via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D25403#580444, @jlebar wrote:

> //Let "CE" mean "constexpr-evaluatable". //
>
> libc++ attempts to be backwards-compatible with old versions of clang, right?


Yea, we'd need to ifdef the test for older versions of Clang. I've just 
summarized my overall proposal in a previous comment.

> Old versions of clang are going to fail, since the builtin will not be CE.  
> Is the idea to write a test that checks that, if `__builtin_isfinite` is CE, 
> then `__libcpp_isfinite` is also CE?  AIUI you can only test CE-ness by 
> detecting a compile failure failure.
> 
> So is the idea that we would have a shell script that tries to compile a 
> file, checking for CE-ness of the builtins, and,  if and only if that 
> succeeds, then checks for CE-ness of __libcpp_isfinite?




https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar added a comment.

//Let "CE" mean "constexpr-evaluatable". //

libc++ attempts to be backwards-compatible with old versions of clang, right?  
Old versions of clang are going to fail, since the builtin will not be CE.  Is 
the idea to write a test that checks that, if __builtin_isfinite is CE, then 
__libcpp_isfinite is also CE?  AIUI you can only test CE-ness by detecting a 
compile failure failure.

So is the idea that we would have a shell script that tries to compile a file, 
checking for CE-ness of the builtins, and,  if and only if that succeeds, then 
checks for CE-ness of __libcpp_isfinite?


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Hal Finkel via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D25403#580439, @jlebar wrote:

> > I'm not sure about that. It seems like a useful feature for the builtins to 
> > have. Logically speaking, they should be constexpr.
>
> I agree that it's logically correct for the builtins to be 
> constexpr-evaluatable.  My point is just that doing this work and then 
> writing a test doesn't buy us much in terms of ensuring that CUDA compilation 
> doesn't break due to changes to libc++.


True, it is not an e2e test, but it could insure that this is not the problem.

> 
> 
>>> In addition, if I understand you correctly, we wouldn't be able to test all 
>>> of the functions here, only the ones that call builtins.
>> 
>> What do you mean?
> 
> This patch adds constexpr to six function definitions, but only three of them 
> directly call a builtin.  If I understand your proposal correctly, the other 
> three function definitions would remain not-constexpr-evaluatable, and thus 
> untested.

Well, we don't know about the others because it would depend on what function 
was found by ADL (potentially). Given that we only use these functions right 
now in , and how  behaves for non-builtin floating-point 
types is not defined, I suspect this is much less concerning.


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar added a comment.

> I'm not sure about that. It seems like a useful feature for the builtins to 
> have. Logically speaking, they should be constexpr.

I agree that it's logically correct for the builtins to be 
constexpr-evaluatable.  My point is just that doing this work and then writing 
a test doesn't buy us much in terms of ensuring that CUDA compilation doesn't 
break due to changes to libc++.

>> In addition, if I understand you correctly, we wouldn't be able to test all 
>> of the functions here, only the ones that call builtins.
> 
> What do you mean?

This patch adds constexpr to six function definitions, but only three of them 
directly call a builtin.  If I understand your proposal correctly, the other 
three function definitions would remain not-constexpr-evaluatable, and thus 
untested.


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Hal Finkel via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D25403#580432, @jlebar wrote:

> In https://reviews.llvm.org/D25403#580422, @hfinkel wrote:
>
> > Okay. Why not fix the Clang builtins so that they're evaluatable for 
> > constant inputs in a constexpr context? Then we can do this and test the 
> > change.
>
>
> I am not sure how much value we would derive from testing specifically that 
> these functions are constexpr-evaluatable?  The thing we actually care about 
> is whether clang can wrap the libc++ `` header in cuda mode, and 
> that could break by removing these constexprs, or by adding a new function 
> used in `` and not marking it constexpr, or in any number of other 
> ways.
>
> Conversely, if `` stopped relying on these functions, we wouldn't 
> care if they stopped being constexpr.


I'm not sure about that. It seems like a useful feature for the builtins to 
have. Logically speaking, they should be constexpr.

> In addition, if I understand you correctly, we wouldn't be able to test all 
> of the functions here, only the ones that call builtins.

What do you mean?

> We have an e2e test for this in the test-suite -- it's currently only enabled 
> for libstdc++.  We haven't yet hooked this up to send out emails when it 
> fails, but if you wanted to block this change on that, I'd totally be 
> onboard.  We also similarly have tests in the test-suite for  and 
> , which have similar failure modes to .




https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar added a comment.

In https://reviews.llvm.org/D25403#580422, @hfinkel wrote:

> Okay. Why not fix the Clang builtins so that they're evaluatable for constant 
> inputs in a constexpr context? Then we can do this and test the change.


I am not sure how much value we would derive from testing specifically that 
these functions are constexpr-evaluatable?  The thing we actually care about is 
whether clang can wrap the libc++ `` header in cuda mode, and that 
could break by removing these constexprs, or by adding a new function used in 
`` and not marking it constexpr, or in any number of other ways.

Conversely, if `` stopped relying on these functions, we wouldn't care 
if they stopped being constexpr.

In addition, if I understand you correctly, we wouldn't be able to test all of 
the functions here, only the ones that call builtins.

We have an e2e test for this in the test-suite -- it's currently only enabled 
for libstdc++.  We haven't yet hooked this up to send out emails when it fails, 
but if you wanted to block this change on that, I'd totally be onboard.  We 
also similarly have tests in the test-suite for  and , which 
have similar failure modes to .


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Hal Finkel via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D25403#580416, @jlebar wrote:

> > Is this because the functions are in  instead of in  are 
> > you don't want to mark all of  as host/device?
>
> Yes.  cmath is its own beast; we need to have our own implementation of it in 
> order to direct the std functions to the appropriate low-level device 
> functions.  (And even if this could somehow be made to work with libc++, we'd 
> still need it for libstdc++, so doing it one way, even if it's horrible, is 
> very likely preferable to doing it two ways.)


Okay. Why not fix the Clang builtins so that they're evaluatable for constant 
inputs in a constexpr context? Then we can do this and test the change.


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar added a comment.

> Is this because the functions are in  instead of in  are you 
> don't want to mark all of  as host/device?

Yes.  cmath is its own beast; we need to have our own implementation of it in 
order to direct the std functions to the appropriate low-level device 
functions.  (And even if this could somehow be made to work with libc++, we'd 
still need it for libstdc++, so doing it one way, even if it's horrible, is 
very likely preferable to doing it two ways.)


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Hal Finkel via cfe-commits]

hfinkel added a comment.

...

> 
> 
>> I guess I don't understand the motivation for this change.
> 
> To make  work in CUDA, we do the following terrible, awful, 
> horrible, no good thing: ...well, I can just show you the code.  
> https://github.com/llvm-project/llvm-project/blob/master/clang/lib/Headers/cuda_wrappers/complex
> 
> The significant part here is
> 
>   #pragma clang force_cuda_host_device begin
>   #include_next 
>   #pragma clang force_cuda_host_device end
>
> 
> This tells clang, everything between the two pragmas is something that we can 
> run on the host (CPU) and device (GPU).  And that works fine for libstdc++.  
> But for libc++, marking everything inside  as host+device is not 
> enough -- we also need to mark these four functions, which are called from 
> .

Is this because the functions are in  instead of in  are you 
don't want to mark all of  as host/device?

> We could mark them as __host__ __device__ explicitly, but then we'd need 
> checks for CUDA compilation inside of libc++, and I've been avoiding asking 
> for that.  Instead, marking these functions as constexpr works, because 
> constexpr functions are implicitly host+device in our CUDA implementation.




https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar added a comment.

Friendly ping?


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar added a comment.

In https://reviews.llvm.org/D25403#573666, @mclow.lists wrote:

> Yesterday and today is the first time in a while that clang has been 
> seriously broken for more than an hour or so.
>  I'm not inclined to worry about it yet.


Oh, awesome.  That sounds good to me.

The question about build configurations still stands, though -- should that be 
documented somewhere?  In particular I could not successfully run check-cxx by 
following the directions I found by googling.  I am volunteering to write the 
patch if we can agree on what the workflow should be.

>>> I don't see how this can possibly be constexpr.
>>>  it calls isfinite(), which is hoisted from ::isfinite(), which comes from 
>>> the C library.
>>>  Since C knows nothing about constexpr, we're stuck.
>> 
>> Functions that call non-constexpr things can be marked constexpr; you just 
>> can't evaluate them in a constexpr context (as you demonstrated).
>> 
>> All I need is for the function to be marked as constexpr; I do not need the 
>> function be constexpr-evaluatable.
> 
> Then what's the point? How can you test if it is correct?

https://reviews.llvm.org/D24971 tests this.  I suppose we could write a test 
inside libcxx, but it would be kind of ugly.

> I guess I don't understand the motivation for this change.

To make  work in CUDA, we do the following terrible, awful, horrible, 
no good thing: ...well, I can just show you the code.  
https://github.com/llvm-project/llvm-project/blob/master/clang/lib/Headers/cuda_wrappers/complex

The significant part here is

  #pragma clang force_cuda_host_device begin
  #include_next 
  #pragma clang force_cuda_host_device end

This tells clang, everything between the two pragmas is something that we can 
run on the host (CPU) and device (GPU).  And that works fine for libstdc++.  
But for libc++, marking everything inside  as host+device is not 
enough -- we also need to mark these four functions, which are called from 
.

We could mark them as __host__ __device__ explicitly, but then we'd need checks 
for CUDA compilation inside of libc++, and I've been avoiding asking for that.  
Instead, marking these functions as constexpr works, because constexpr 
functions are implicitly host+device in our CUDA implementation.


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Marshall Clow via cfe-commits]

mclow.lists added a comment.

In https://reviews.llvm.org/D25403#573104, @jlebar wrote:

> Likewise, should I update the documentation to indicate that check-cxx may 
> fail with a clang built from tip of tree, due to c++17 support being 
> experimental?  Or do you all want to change the target so that it doesn't run 
> the c++17 tests by default?  This burned about an hour of developer time 
> yesterday, I guess because we couldn't believe that check-cxx would be 
> intentionally broken like that, so it would be nice to have some sort of fix.


Yesterday and today is the first time in a while that clang has been seriously 
broken for more than an hour or so.
I'm not inclined to worry about it yet.

>> I don't see how this can possibly be constexpr.
>>  it calls isfinite(), which is hoisted from ::isfinite(), which comes from 
>> the C library.
>>  Since C knows nothing about constexpr, we're stuck.
> 
> Functions that call non-constexpr things can be marked constexpr; you just 
> can't evaluate them in a constexpr context (as you demonstrated).
> 
> All I need is for the function to be marked as constexpr; I do not need the 
> function be constexpr-evaluatable.

Then what's the point? How can you test if it is correct?

> I think the implications of this change would be that, if you evaluated this 
> function in a constexpr context, before the change would be a compile error 
> when calling __libcpp_isnan, and after this change it would be a compile 
> error at calling ::isnan.  Since the function should not be called outside of 
> libc++ anyway, I was hoping that wouldn't make a difference to anyone.

I guess I don't understand the motivation for this change.


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar added a comment.

Thank you, Marshall.

In https://reviews.llvm.org/D25403#572998, @mclow.lists wrote:

> My build setup is similar to yours (on Mac OS X):
>
>   cd $LLVM_BUILD ; rm -rf libcxx ; mkdir libcxx ; cd libcxx 
>   CXX=$LLVM_BIN/clang++ cmake -DLLVM_PATH=$LLVM/llvm 
> -DLIBCXX_CXX_ABI=libcxxabi -DLIBCXX_CXX_ABI_INCLUDE_PATHS=/usr/include $LIBCXX
>   make  # build libc++
>   make check-libcxx # run the tests


Ah, it's -DLIBCXX_CXX_ABI and -DLIBCXX_CXX_ABI_INCLUDE_PATHS that I was missing.

Is this the recommended way of building libcxx?  Should I update the 
documentation?

Likewise, should I update the documentation to indicate that check-cxx may fail 
with a clang built from tip of tree, due to c++17 support being experimental?  
Or do you all want to change the target so that it doesn't run the c++17 tests 
by default?  This burned about an hour of developer time yesterday, I guess 
because we couldn't believe that check-cxx would be intentionally broken like 
that, so it would be nice to have some sort of fix.

> I don't see how this can possibly be constexpr.
>  it calls isfinite(), which is hoisted from ::isfinite(), which comes from 
> the C library.
>  Since C knows nothing about constexpr, we're stuck.

Functions that call non-constexpr things can be marked constexpr; you just 
can't evaluate them in a constexpr context (as you demonstrated).

All I need is for the function to be marked as constexpr; I do not need the 
function be constexpr-evaluatable.

I think the implications of this change would be that, if you evaluated this 
function in a constexpr context, before the change would be a compile error 
when calling __libcpp_isnan, and after this change it would be a compile error 
at calling ::isnan.  Since the function should not be called outside of libc++ 
anyway, I was hoping that wouldn't make a difference to anyone.


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Marshall Clow via cfe-commits]

mclow.lists added a comment.

> error: undefined reference to '__gxx_personality_v0'

means that you're not linking to an ABI library.

That symbol comes out of libc++abi, but you can also get that from libsupc.

My build setup is similar to yours (on Mac OS X):

  cd $LLVM_BUILD ; rm -rf libcxx ; mkdir libcxx ; cd libcxx 
  CXX=$LLVM_BIN/clang++ cmake -DLLVM_PATH=$LLVM/llvm -DLIBCXX_CXX_ABI=libcxxabi 
-DLIBCXX_CXX_ABI_INCLUDE_PATHS=/usr/include $LIBCXX
  make  # build libc++
  make check-libcxx # run the tests




Comment at: libcxx/include/cmath:615
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, 
bool>::type
 __libcpp_isfinite(_A1 __lcpp_x) _NOEXCEPT

I don't see how this can possibly be constexpr.
it calls `isfinite()`, which is hoisted from `::isfinite()`, which comes from 
the C library.
Since C knows nothing about constexpr, we're stuck.

I just tried this:
constexpr float f = 3.2f;
static_assert(::isfinite(f), "" );

and got:
bug.cpp:9:19: error: static_assert expression is not an integral constant 
expression
static_assert(::isfinite(f), "" );
  ^



https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar added a comment.

> The tests should be runnable with lit. I generally just do an in-tree build 
> and run make check-libcxx. @EricWF , what's the recommended way of running 
> the tests from an out-of-tree build?

Things seem broken at the moment with clang from tip of tree.

I did a clean in-tree build and then modified the `config.cxx_under_test` line 
in projects/libcxx/test/lit.site.cfg to point to my newly-built clang.  Running 
check-cxx gets tons of failing tests [1].  However, if I change that to point 
to my clang-3.8 binary, everything works fine, with and without this patch here.

So, issues with libc++ and current clang aside (I'm happy to file a bug 
somewhere?), this patch seems to pass the tests just fine.

Would be nice to get this in -- it's the only thing blocking me from turning on 
these tests in the test suite (and announcing full support for std::complex on 
the device).

[1]  One example of a failing test:

  

FAIL: libc++ :: 
std/containers/container.adaptors/priority.queue/priqueue.cons/ctor_move.pass.cpp
 (732 of 5634)
 TEST 'libc++ :: 
std/containers/container.adaptors/priority.queue/priqueue.cons/ctor_move.pass.cpp'
 FAILED 
Command: ['/usr/local/google/home/jlebar/llvm/release/bin/clang++', '-o', 
'/usr/local/google/home/jlebar/code/llvm/release/projects/libcxx/test/std/containers/container.adaptors/priority.queue/priqueue.cons/Output/ctor_move.pass.cpp.o',
 '-x', 'c++', 
'/usr/local/google/home/jlebar/code/llvm/libcxx/test/std/containers/container.adaptors/priority.queue/priqueue.cons/ctor_move.pass.cpp',
 '-c', '-v', '-Werror=thread-safety', '-std=c++1z', '-include', 
'/usr/local/google/home/jlebar/llvm/llvm/projects/libcxx/test/support/nasty_macros.hpp',
 '-nostdinc++', 
'-I/usr/local/google/home/jlebar/llvm/llvm/projects/libcxx/include', 
'-D__STDC_FORMAT_MACROS', '-D__STDC_LIMIT_MACROS', '-D__STDC_CONSTANT_MACROS', 
'-I/usr/local/google/home/jlebar/llvm/llvm/projects/libcxx/test/support', 
'-DLIBCXX_FILESYSTEM_STATIC_TEST_ROOT="/usr/local/google/home/jlebar/code/llvm/libcxx/test/std/experimental/filesystem/Inputs/static_test_env"',
 
'-DLIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT="/usr/local/google/home/jlebar/code/llvm/release/projects/libcxx/test/filesystem/Output/dynamic_env"',
 '-DLIBCXX_FILESYSTEM_DYNAMIC_TEST_HELPER="/usr/bin/python2.7 
/usr/local/google/home/jlebar/llvm/llvm/projects/libcxx/test/support/filesystem_dynamic_test_helper.py"',
 '-c']
Exit Code: 1
Standard Error:
--
clang version 4.0.0 
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/google/home/jlebar/llvm/release/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
Found CUDA installation: /usr/local/cuda, version 7.0
 "/usr/local/google/home/jlebar/code/llvm/release/bin/clang-4.0" -cc1 
-triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free 
-main-file-name ctor_move.pass.cpp -mrelocation-model static -mthread-model 
posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases 
-munwind-tables -fuse-init-array -target-cpu x86-64 -v -dwarf-column-info 
-debugger-tuning=gdb -coverage-notes-file 
/usr/local/google/home/jlebar/code/llvm/release/projects/libcxx/test/std/containers/container.adaptors/priority.queue/priqueue.cons/Output/ctor_move.pass.cpp.gcno
 -nostdinc++ -resource-dir 
/usr/local/google/home/jlebar/code/llvm/release/bin/../lib/clang/4.0.0 -include 
/usr/local/google/home/jlebar/llvm/llvm/projects/libcxx/test/support/nasty_macros.hpp
 -I /usr/local/google/home/jlebar/llvm/llvm/projects/libcxx/include -D 
__STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS -I 
/usr/local/google/home/jlebar/llvm/llvm/projects/libcxx/test/support -D 
"LIBCXX_FILESYSTEM_STATIC_TEST_ROOT=\"/usr/local/google/home/jlebar/code/llvm/libcxx/test/std/experimental/filesystem/Inputs/static_test_env\""
 -D 
"LIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT=\"/usr/local/google/home/jlebar/code/llvm/release/projects/libcxx/test/filesystem/Output/dynamic_env\""
 -D "LIBCXX_FILESYSTEM_DYNAMIC_TEST_HELPER=\"/usr/bin/python2.7 
/usr/local/google/home/jlebar/llvm/llvm/projects/libcxx/test/support/filesystem_dynamic_test_helper.py\""
 -internal-isystem /usr/local/include -internal-isystem 
/usr/local/google/home/jlebar/code/llvm/release/bin/../lib/clang/4.0.0/include 

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Hal Finkel via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D25403#565603, @jlebar wrote:

> Although these pass the CUDA test-suite tests (which I haven't yet committed 
> because they're broken without this change), I could use some help running 
> the libcxx tests.
>
> I cannot find any documentation explaining how to run the libcxx tests with 
> just-built clang.  Presumably this is supported and I just cannot figure it 
> out.  Anyway I figured I'd try to make a new objdir and point it to my 
> just-built clang.
>
>   $ mkdir objdir-libcxx
>   $ cd objdir-libcxx
>   $ cmake -G "Ninja" -DCMAKE_BUILD_TYPE=Release 
> -DCMAKE_C_COMPILER=$HOME/llvm/release/bin/clang 
> -DCMAKE_CXX_COMPILER=$HOME/llvm/release/bin/clang -DLLVM_ENABLE_ASSERTIONS=On 
> ../llvm
>   
>
> This also doesn't work.  Building one of cmake's atomic tests fails with 
> linker errors.
>
>   Run Build Command:"/usr/local/google/home/jlebar/bin/ninja" "cmTC_0c40a"
>   [1/2] Building CXX object CMakeFiles/cmTC_0c40a.dir/src.cxx.o
>   [2/2] Linking CXX executable cmTC_0c40a
>   FAILED: cmTC_0c40a
>   : && /usr/local/google/home/jlebar/llvm/release/bin/clang   
> -DHAVE_CXX_ATOMICS_WITH_LIB -std=c++11   CMakeFiles/cmTC_0c40a.dir/src.cxx.o  
> -o cmTC_0c40a  -lm -latomic && :
>   CMakeFiles/cmTC_0c40a.dir/src.cxx.o:src.cxx:function 
> __clang_call_terminate: error: undefined reference to '__cxa_begin_catch'
>   CMakeFiles/cmTC_0c40a.dir/src.cxx.o:src.cxx:function 
> __clang_call_terminate: error: undefined reference to 'std::terminate()'
>   CMakeFiles/cmTC_0c40a.dir/src.cxx.o(.eh_frame+0x143): error: undefined 
> reference to '__gxx_personality_v0'
>   clang-4.0: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>   ninja: build stopped: subcommand failed.
>   
>   Source file was:
>   
>   #include 
>   std::atomic x;
>   int main() {
> return x;
>   }
>   
>
> I presume there is some Right Way to do this, and I'm just not doing it.


The tests should be runnable with lit. I generally just do an in-tree build and 
run make check-libcxx. @EricWF , what's the recommended way of running the 
tests from an out-of-tree build?


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar added a comment.

Although these pass the CUDA test-suite tests (which I haven't yet committed 
because they're broken without this change), I could use some help running the 
libcxx tests.

I cannot find any documentation explaining how to run the libcxx tests with 
just-built clang.  Presumably this is supported and I just cannot figure it 
out.  Anyway I figured I'd try to make a new objdir and point it to my 
just-built clang.

  $ mkdir objdir-libcxx
  $ cd objdir-libcxx
  $ cmake -G "Ninja" -DCMAKE_BUILD_TYPE=Release 
-DCMAKE_C_COMPILER=$HOME/llvm/release/bin/clang 
-DCMAKE_CXX_COMPILER=$HOME/llvm/release/bin/clang -DLLVM_ENABLE_ASSERTIONS=On 
../llvm

This also doesn't work.  Building one of cmake's atomic tests fails with linker 
errors.

  Run Build Command:"/usr/local/google/home/jlebar/bin/ninja" "cmTC_0c40a"
  [1/2] Building CXX object CMakeFiles/cmTC_0c40a.dir/src.cxx.o
  [2/2] Linking CXX executable cmTC_0c40a
  FAILED: cmTC_0c40a
  : && /usr/local/google/home/jlebar/llvm/release/bin/clang   
-DHAVE_CXX_ATOMICS_WITH_LIB -std=c++11   CMakeFiles/cmTC_0c40a.dir/src.cxx.o  
-o cmTC_0c40a  -lm -latomic && :
  CMakeFiles/cmTC_0c40a.dir/src.cxx.o:src.cxx:function __clang_call_terminate: 
error: undefined reference to '__cxa_begin_catch'
  CMakeFiles/cmTC_0c40a.dir/src.cxx.o:src.cxx:function __clang_call_terminate: 
error: undefined reference to 'std::terminate()'
  CMakeFiles/cmTC_0c40a.dir/src.cxx.o(.eh_frame+0x143): error: undefined 
reference to '__gxx_personality_v0'
  clang-4.0: error: linker command failed with exit code 1 (use -v to see 
invocation)
  ninja: build stopped: subcommand failed.
  
  Source file was:
  
  #include 
  std::atomic x;
  int main() {
return x;
  }

I presume there is some Right Way to do this, and I'm just not doing it.


https://reviews.llvm.org/D25403



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

[Justin Lebar via cfe-commits]

jlebar created this revision.
jlebar added a reviewer: hfinkel.
jlebar added a subscriber: cfe-commits.

This makes these functions available on host and device, which is
necessary to compile  for the device.


https://reviews.llvm.org/D25403

Files:
  libcxx/include/cmath


Index: libcxx/include/cmath
===
--- libcxx/include/cmath
+++ libcxx/include/cmath
@@ -560,7 +560,7 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isnan(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isnan)
@@ -572,15 +572,15 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, 
bool>::type
 __libcpp_isnan(_A1 __lcpp_x) _NOEXCEPT
 {
 return isnan(__lcpp_x);
 }
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isinf(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isinf)
@@ -592,15 +592,15 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, 
bool>::type
 __libcpp_isinf(_A1 __lcpp_x) _NOEXCEPT
 {
 return isinf(__lcpp_x);
 }
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isfinite(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isfinite)
@@ -612,7 +612,7 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, 
bool>::type
 __libcpp_isfinite(_A1 __lcpp_x) _NOEXCEPT
 {
 return isfinite(__lcpp_x);


Index: libcxx/include/cmath
===
--- libcxx/include/cmath
+++ libcxx/include/cmath
@@ -560,7 +560,7 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isnan(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isnan)
@@ -572,15 +572,15 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isnan(_A1 __lcpp_x) _NOEXCEPT
 {
 return isnan(__lcpp_x);
 }
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isinf(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isinf)
@@ -592,15 +592,15 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isinf(_A1 __lcpp_x) _NOEXCEPT
 {
 return isinf(__lcpp_x);
 }
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isfinite(_A1 __lcpp_x) _NOEXCEPT
 {
 #if __has_builtin(__builtin_isfinite)
@@ -612,7 +612,7 @@
 
 template 
 _LIBCPP_ALWAYS_INLINE
-typename enable_if::value, bool>::type
+_LIBCPP_CONSTEXPR typename enable_if::value, bool>::type
 __libcpp_isfinite(_A1 __lcpp_x) _NOEXCEPT
 {
 return isfinite(__lcpp_x);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits