Summary:
This makes these functions available on host and device, which is
necessary to compile <complex> for the device.
Reviewers: hfinkel, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25403
llvm-svn: 287012
Visual Studio 2013 and up have these functions, and we don't need to
support older versions.
There are some remaining _LIBCPP_MSVCRT exclusions which are present on
Visual Studio 2015 but not 2013. Those will be addressed in a follow-up.
Differential Revision: https://reviews.llvm.org/D26377
llvm-svn: 286202
The libc-provided isnan/isinf/isfinite macro implementations are specifically
designed to function correctly, even in the presence of -ffast-math (or, more
specifically, -ffinite-math-only). As such, on most implementation, these
either always turn into external function calls (e.g. glibc) or are
specifically function calls when FINITE_MATH_ONLY is defined (e.g. Darwin).
Our implementation of complex arithmetic makes heavy use of isnan/isinf/isfinite
to deal with corner cases involving non-finite quantities. This was problematic
in two respects:
1. On systems where these are always function calls (e.g. Linux/glibc), there was a
performance penalty
2. When compiling with -ffast-math, there was a significant performance
penalty (in fact, on Darwin and systems with similar implementations, the code
may in fact be slower than not using -ffast-math, because the inline
definitions provided by libc become unavailable to prevent the checks from
being optimized out).
Eliding these inf/nan checks in -ffast-math mode is consistent with what
happens with libstdc++, and in my experience, what users expect. This is
critical to getting high-performance code when using complex<T>. This change
replaces uses of those functions on basic floating-point types with calls to
__builtin_isnan/isinf/isfinite, which Clang will always expand inline. When
using -ffast-math (or -ffinite-math-only), the optimizer will remove the checks
as expected.
Differential Revision: https://reviews.llvm.org/D18639
llvm-svn: 283051
1) <cstdlib> header should define std::abs([int|long|long long])
functions. They use "using ::abs" to import these functions (which are
declared in <stdlib.h>) into std namespace.
2) <cmath> header should define std::abs([float|double|long double])
function. If we try define new functions in std namespace, then it
will cause compile error in <cstdlib> because "using ::abs" will try
import not only [int|long|long long] functions, but also
[float|double|long double] which are defined in <math.h> header on
solaris.
Patch by C Bergstrom.
llvm-svn: 232641
MSVCRT 12.0 introduces better compatibility for C99. This includes a number of
math routines that were previously undefined. Use the crtversion.h header to
detect the version of MSVCRT being targeted and avoid re-declaring the
variables.
Since copysign has been introduced in MSVCRT, importing the definition via using
makes it difficult to provide overloads (due to minor differences between
throw () and noexcept. Avoid defining the overloads on newer MSVCRT
targets.
llvm-svn: 230867
Delay instantiation of `__numeric_type` within <cmath>,
don't instantiate it when the `is_arithmetic` conditions do not hold as it causes
errors with user-defined types with ambiguous conversions. Fixes PR21083.
llvm-svn: 219998
MSVC-specific, MSVCRT-specific, or Windows-specific. Because Clang can
also define _MSC_VER, and MSVCRT is not necessarily the only C runtime,
these macros should not be used interchangeably.
This patch divides all Windows-related bits into the aforementioned
categories. Two new macros are introduced:
- _LIBCPP_MSVC: Defined when compiling with MSVC. Detected using
_MSC_VER, excluding Clang.
- _LIBCPP_MSVCRT: Defined when using the Microsoft CRT. This is the default
when _WIN32 is defined.
This leaves _WIN32 for code using the Windows API.
This also corrects the spelling of _LIBCP_HAS_IS_BASE_OF to _LIBCPP_HAS_IS_BASE_OF.
Nico, please prepare a patch for CREDITS.TXT, thanks.
llvm-svn: 187593
Solaris not providing some of the locales that the test suite uses.
Note: This depends on an xlocale (partial) implementation for Solaris and a
couple of fixed standard headers. These will be committed to a branch later
today.
llvm-svn: 151720
Justin Lebar