| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Certain C libraries require configuration macros defined in __config
to provide the correct functionality for libc++. This patch ensures
that the C header math.h is always included after the __config
header. It also adds a Windows-specific #if guard for the case when
the C math.h file is included the second time, as suggested by
Marshall in https://reviews.llvm.org/rL323490.
Fixes PR36382.
Reviewers: mclow.lists, EricWF
Reviewed By: mclow.lists
Subscribers: cfe-commits, pcc, christof, rogfer01
Differential Revision: https://reviews.llvm.org/D43579
llvm-svn: 325760
|
|
|
|
| |
llvm-svn: 325740
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D42503
llvm-svn: 325723
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently std::asinh and std::acosh use std::pow to compute x^2. This
results in a significant error when computing e.g. asinh(i) or
acosh(-1).
This patch expresses x^2 directly via x.real() and x.imag(), like it
is done in libstdc++/glibc, and adds tests that checks the accuracy.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D41629
llvm-svn: 325510
|
|
|
|
| |
llvm-svn: 325205
|
|
|
|
|
|
| |
2GB. (like say 32-bit big-endian)
llvm-svn: 325147
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43167
llvm-svn: 325087
|
|
|
|
| |
llvm-svn: 325028
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Compiling `<functional>` in C++17 or higher mode results in:
```
functional:2500:1: warning: attribute '__visibility__' is ignored, place it after "class" to apply attribute to type declaration [-Wignored-attributes]
_LIBCPP_TYPE_VIS
^
__config:701:46: note: expanded from macro '_LIBCPP_TYPE_VIS'
# define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
^
1 warning generated.
```
Fix it by putting the attribute after the `class` keyword.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43209
llvm-svn: 325027
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43224
llvm-svn: 324989
|
|
|
|
| |
llvm-svn: 324959
|
|
|
|
| |
llvm-svn: 324923
|
|
|
|
|
|
| |
more, and mark 2878 as complete as well (we already do that)
llvm-svn: 324911
|
|
|
|
|
|
| |
non-public uses of decay that could be replaced by __uncvref. NFC intented
llvm-svn: 324895
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As noted in a discussion about testing the LLVM 6.0.0 release candidates
(with libc++) for FreeBSD, many tests turned out to fail with
"exception_ptr not yet implemented". This was because libc++ did not
choose the correct C++ ABI library, and therefore it fell back to the
`exception_fallback.ipp` header.
Since FreeBSD 10.x, we have been using libcxxrt as our C++ ABI library,
and its headers have always been installed in /usr/include/c++/v1,
together with the (system) libc++ headers. (Older versions of FreeBSD
used GNU libsupc++ by default, but these are now unsupported.)
Therefore, if we are building libc++ for FreeBSD, set:
* `LIBCXX_CXX_ABI_LIBNAME` to "libcxxrt"
* `LIBCXX_CXX_ABI_INCLUDE_PATHS` to "/usr/include/c++/v1"
by default.
Reviewers: emaste, EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: mgorny, cfe-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D43166
llvm-svn: 324855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch from charlieio@outlook.com
Reviewed as https://reviews.llvm.org/D42354
When the following command is used:
> clang-cl -std:c++17 -Iinclude\c++\v1 hello.cc c++.lib
An error occurred:
In file included from hello.cc:1:
In file included from include\c++\v1\iostream:38:
In file included from include\c++\v1\ios:216:
In file included from include\c++\v1\__locale:15:
In file included from include\c++\v1\string:477:
In file included from include\c++\v1\string_view:176:
In file included from include\c++\v1\__string:56:
In file included from include\c++\v1\algorithm:643:
In file included from include\c++\v1\memory:656:
include\c++\v1\new(165,29): error: redefinition of 'align_val_t'
enum class _LIBCPP_ENUM_VIS align_val_t : size_t { };
^
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\include\vcruntime_new.h(43,16): note:
previous definition is here
enum class align_val_t : size_t {};
^
1 error generated.
vcruntime_new.h has defined align_val_t, libcxx need hide align_val_t.
This patch fixes that error.
llvm-svn: 324853
|
|
|
|
| |
llvm-svn: 324852
|
|
|
|
| |
llvm-svn: 324851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch from ngolovliov@gmail.com
Reviewed as: https://reviews.llvm.org/D42344
As described in llvm.org/PR30959, the current
implementation of std::{map, key}::{count, equal_range} in libcxx is
non-conforming. Quoting the C++14 standard [associative.reqmts]p3
> The phrase “equivalence of keys” means the equivalence relation imposed by
> the comparison and not the operator== on keys. That is, two keys k1 and k2 are
> considered to be equivalent if for the comparison object comp,
> comp(k1, k2) == false && comp(k2, k1) == false.
In the same section, the requirements table states the following:
> a.equal_range(k) equivalent to make_pair(a.lower_bound(k), a.upper_bound(k))
> a.count(k) returns the number of elements with key equivalent to k
The behaviour of libstdc++ seems to conform to the standard here.
llvm-svn: 324799
|
|
|
|
| |
llvm-svn: 324640
|
|
|
|
| |
llvm-svn: 324624
|
|
|
|
|
|
| |
unsupported, b/c they don't have deduction guides, even in C++17 mode
llvm-svn: 324619
|
|
|
|
| |
llvm-svn: 324609
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently libc++ implements some operations on valarray by using the
resize method. This method has a parameter with a default value.
Because of this, valarray may spuriously construct and destruct
objects of valarray's element type.
This patch fixes this issue and adds corresponding test cases.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: rogfer01, cfe-commits
Differential Revision: https://reviews.llvm.org/D41992
llvm-svn: 324596
|
|
|
|
|
|
| |
with old bots
llvm-svn: 324573
|
|
|
|
| |
llvm-svn: 324569
|
|
|
|
| |
llvm-svn: 324566
|
|
|
|
|
|
|
|
| |
An array T[1] isn't necessarily the same say when it's
a member of a struct. This patch addresses that problem and corrects
the tests to deal with it.
llvm-svn: 324545
|
|
|
|
|
|
|
| |
Fallback implementations are now provided by bionic when necessary,
which these may conflict with.
llvm-svn: 324534
|
|
|
|
|
|
| |
sizeof(T)>sizeof(long long)'. We were mishandling the small-string optimization calculations for very large 'characters'. This may be an ABI change (change the size of) strings of very large 'characters', but since they never worked, I'm not too concerned.
llvm-svn: 324531
|
|
|
|
| |
llvm-svn: 324529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructible types.
Summary:
This patch fixes llvm.org/PR35491 and LWG2157 (https://cplusplus.github.io/LWG/issue2157)
The fix attempts to maintain ABI compatibility by replacing the array with a instance of `aligned_storage`.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: lichray, cfe-commits
Differential Revision: https://reviews.llvm.org/D41223
llvm-svn: 324526
|
|
|
|
| |
llvm-svn: 324503
|
|
|
|
|
|
| |
type aliases, conjunction/disjunction, apply, etc. See https://libcxx.llvm.org/TS_deprecation.html
llvm-svn: 324423
|
|
|
|
| |
llvm-svn: 324399
|
|
|
|
| |
llvm-svn: 324398
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
or lower.
The 10.13 SDK always defines utimensat() (with an availability(macosx=10.13) annotation)
and unconditionally defines UTIME_OMIT, so use the compile-time availability macros
on Apple platforms instead.
For people statically linking libc++, it might make sense to also provide an opt-in
option for using __builtin_available() to dynamically check for the OS version,
but for now let's do the smallest thing needed to unbreak the build.
Based on a patch by Eric Fiselier <eric@efcs.ca>: https://reviews.llvm.org/D34249
Fixes PR33469.
llvm-svn: 324385
|
|
|
|
|
|
| |
https://reviews.llvm.org/D42945 ; thanks to Bruce Mitchener for the patch.
llvm-svn: 324378
|
|
|
|
| |
llvm-svn: 324312
|
|
|
|
| |
llvm-svn: 324310
|
|
|
|
|
|
|
|
|
|
|
| |
non-default constructible types."
Revert "Fix initialization of array<const T, 0> with GCC."
Revert "Make array<const T, 0> non-CopyAssignable and make swap and fill ill-formed."
This reverts commit r324182, r324185, and r324194 which were causing issues with zero-length std::arrays.
llvm-svn: 324309
|
|
|
|
| |
llvm-svn: 324307
|
|
|
|
| |
llvm-svn: 324292
|
|
|
|
|
|
| |
https://libcxx.llvm.org/TS_deprecation.html
llvm-svn: 324290
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, when handling zero-sized array of const objects we
used a const version of aligned_storage_t, which is not an array type.
However, GCC complains about initialization of the form: array<const T, 0> arr = {};
This patch fixes that bug by making the dummy object used to represent
the zero-sized array an array itself. This avoids GCC's complaints
about the uninitialized const member.
llvm-svn: 324194
|
|
|
|
| |
llvm-svn: 324193
|
|
|
|
|
|
|
|
|
| |
This patch removes the noexcept declaration from filesystem
operations which require creating temporary paths or
creating a directory iterator. Either of these operations
can throw.
llvm-svn: 324192
|
|
|
|
| |
llvm-svn: 324191
|
|
|
|
| |
llvm-svn: 324190
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because path can be constructed from a ton of different types, including string
and wide strings, this caused it's streaming operators to suck up all sorts
of silly types via silly conversions. For example:
using namespace std::experimental::filesystem::v1;
std::wstring w(L"wide");
std::cout << w; // converts to path.
This patch tentatively adopts the resolution to LWG2989 and fixes the issue
by making the streaming operators friends of path.
llvm-svn: 324189
|