[PATCH] D34578: cmath: Support clang's -fdelayed-template-parsing

2017-06-23 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith created this revision.

r283051 added some functions to cmath (in namespace std) that have the same 
name as functions in math.h (in the global namespace).  Clang's limited support 
for `-fdelayed-template-parsing` chokes on this.  Rename the ones in `cmath` 
and their uses in `complex` and the test.

(Incidentally, I noticed that r283051 was optimizing the implementation of 
``.  I wonder why we have so much code in that header, instead of 
calling out to libc's already-optimized `` implementation?)

rdar://problem/32848355


https://reviews.llvm.org/D34578

Files:
  libcxx/include/cmath
  libcxx/include/complex
  libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
  libcxx/test/libcxx/numerics/c.math/fdelayed-template-parsing.sh.cpp
  libcxx/utils/libcxx/test/config.py

Index: libcxx/utils/libcxx/test/config.py
===
--- libcxx/utils/libcxx/test/config.py
+++ libcxx/utils/libcxx/test/config.py
@@ -440,6 +440,9 @@
 # C++17 aligned allocation.
 self.config.available_features.add('no-aligned-allocation')
 
+if self.cxx.hasCompileFlag('-fdelayed-template-parsing'):
+self.config.available_features.add('fdelayed-template-parsing')
+
 if self.get_lit_bool('has_libatomic', False):
 self.config.available_features.add('libatomic')
 
Index: libcxx/test/libcxx/numerics/c.math/fdelayed-template-parsing.sh.cpp
===
--- /dev/null
+++ libcxx/test/libcxx/numerics/c.math/fdelayed-template-parsing.sh.cpp
@@ -0,0 +1,28 @@
+//===--===//
+//
+// 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.
+//
+//===--===//
+
+// test that cmath builds with -fdelayed-template-parsing
+
+// REQUIRES: fdelayed-template-parsing
+
+// RUN: %build -fdelayed-template-parsing
+// RUN: %run
+
+#include 
+#include 
+
+#include "test_macros.h"
+
+int main() {
+  assert(std::isfinite(1.0));
+  assert(!std::isinf(1.0));
+  assert(!std::isnan(1.0));
+}
+
+using namespace std;
Index: libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
===
--- libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
+++ libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp
@@ -23,9 +23,9 @@
 
 #include 
 
-static_assert(std::__libcpp_isnan(0.) == false, "");
-static_assert(std::__libcpp_isinf(0.0) == false, "");
-static_assert(std::__libcpp_isfinite(0.0) == true, "");
+static_assert(std::__libcpp_isnan_or_builtin(0.) == false, "");
+static_assert(std::__libcpp_isinf_or_builtin(0.0) == false, "");
+static_assert(std::__libcpp_isfinite_or_builtin(0.0) == true, "");
 
 int main()
 {
Index: libcxx/include/complex
===
--- libcxx/include/complex
+++ libcxx/include/complex
@@ -599,39 +599,39 @@
 _Tp __bc = __b * __c;
 _Tp __x = __ac - __bd;
 _Tp __y = __ad + __bc;
-if (__libcpp_isnan(__x) && __libcpp_isnan(__y))
+if (__libcpp_isnan_or_builtin(__x) && __libcpp_isnan_or_builtin(__y))
 {
 bool __recalc = false;
-if (__libcpp_isinf(__a) || __libcpp_isinf(__b))
+if (__libcpp_isinf_or_builtin(__a) || __libcpp_isinf_or_builtin(__b))
 {
-__a = copysign(__libcpp_isinf(__a) ? _Tp(1) : _Tp(0), __a);
-__b = copysign(__libcpp_isinf(__b) ? _Tp(1) : _Tp(0), __b);
-if (__libcpp_isnan(__c))
+__a = copysign(__libcpp_isinf_or_builtin(__a) ? _Tp(1) : _Tp(0), __a);
+__b = copysign(__libcpp_isinf_or_builtin(__b) ? _Tp(1) : _Tp(0), __b);
+if (__libcpp_isnan_or_builtin(__c))
 __c = copysign(_Tp(0), __c);
-if (__libcpp_isnan(__d))
+if (__libcpp_isnan_or_builtin(__d))
 __d = copysign(_Tp(0), __d);
 __recalc = true;
 }
-if (__libcpp_isinf(__c) || __libcpp_isinf(__d))
+if (__libcpp_isinf_or_builtin(__c) || __libcpp_isinf_or_builtin(__d))
 {
-__c = copysign(__libcpp_isinf(__c) ? _Tp(1) : _Tp(0), __c);
-__d = copysign(__libcpp_isinf(__d) ? _Tp(1) : _Tp(0), __d);
-if (__libcpp_isnan(__a))
+__c = copysign(__libcpp_isinf_or_builtin(__c) ? _Tp(1) : _Tp(0), __c);
+__d = copysign(__libcpp_isinf_or_builtin(__d) ? _Tp(1) : _Tp(0), __d);
+if (__libcpp_isnan_or_builtin(__a))
 __a = copysign(_Tp(0), __a);
-if (__libcpp_isnan(__b))
+if (__libcpp_isnan_or_builtin(__b))
 __b = copysign(_Tp(0), __b);
 __recalc = true;
 }
-if (!__recalc 

[PATCH] D34578: cmath: Support clang's -fdelayed-template-parsing

2017-07-06 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

Ping!  Hal, you committed r283051.  Do you have a problem with this?


https://reviews.llvm.org/D34578



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


[PATCH] D34578: cmath: Support clang's -fdelayed-template-parsing

2017-07-06 Thread Hal Finkel via Phabricator via cfe-commits
hfinkel accepted this revision.
hfinkel added a comment.
This revision is now accepted and ready to land.

In https://reviews.llvm.org/D34578#801357, @dexonsmith wrote:

> Ping!  Hal, you committed r283051.  Do you have a problem with this?


It looks like you're just renaming `__libcpp_isnan` and friends to 
__libcpp_isnan_or_builtin` and similar. LGTM

> (Incidentally, I noticed that r283051 was optimizing the implementation of 
> . I wonder why we have so much code in that header, instead of 
> calling out to libc's already-optimized  implementation?)

This is definitely worth looking at (especially given that we don't support 
complex of user-defined types with those functions). Would making 
complex use _Complex double, and so on, be an API break? Would that 
matter?


https://reviews.llvm.org/D34578



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


[PATCH] D34578: cmath: Support clang's -fdelayed-template-parsing

2017-07-06 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith closed this revision.
dexonsmith added a comment.

In https://reviews.llvm.org/D34578#801519, @hfinkel wrote:

> In https://reviews.llvm.org/D34578#801357, @dexonsmith wrote:
>
> > Ping!  Hal, you committed r283051.  Do you have a problem with this?
>
>
> It looks like you're just renaming `__libcpp_isnan` and friends to 
> __libcpp_isnan_or_builtin` and similar. LGTM


Thanks; committed in r307357.

>> (Incidentally, I noticed that r283051 was optimizing the implementation of 
>> . I wonder why we have so much code in that header, instead of 
>> calling out to libc's already-optimized  implementation?)
> 
> This is definitely worth looking at (especially given that we don't support 
> complex of user-defined types with those functions). Would making 
> complex use _Complex double, and so on, be an API break? Would that 
> matter?

I think paragraph 4 of complex.numbers (from n4640) effectively enforces that 
`complex` and `_Complex T` are ABI-compatible.


https://reviews.llvm.org/D34578



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