| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Was broken by r334477.
llvm-svn: 335507
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The paths output from llvm-config --cmakedir and from clang
--print-libgcc-file-name can contain backslashes, while CMake
can't handle the paths in this form.
This matches what compiler-rt already does (since SVN r203789
and r293195).
Differential Revision: https://reviews.llvm.org/D48356
llvm-svn: 335172
|
|
|
|
|
|
| |
Feature test macro versions may have a trailing L.
llvm-svn: 334917
|
|
|
|
| |
llvm-svn: 334894
|
|
|
|
| |
llvm-svn: 334676
|
|
|
|
|
|
|
|
| |
MSVC's STL removed _SCL_SECURE_NO_WARNINGS.
MSVC's STL implemented feature-test macros.
llvm-svn: 334675
|
|
|
|
|
|
| |
This simplifies the handling of header targets.
llvm-svn: 334477
|
|
|
|
|
|
|
| |
This resolves the breakage introduced in r334468 which results in
build error when using CMake Makefile generator.
llvm-svn: 334470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using file(COPY FILE...) has several downsides. Since the file command
is only executed at configuration time, any changes to headers made
after the initial CMake execution are ignored. This can lead to subtle
errors since the just built Clang will be using stale libc++ headers.
Furthermore, since the headers are copied prior to executing the build
system, this may hide missing dependencies on libc++ from other LLVM
components.
This changes replaces the use of file(COPY FILE...) command with a
custom command and target which addresses all aforementioned issues and
matches the implementation already used by other LLVM components that
also install headers like Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D44773
llvm-svn: 334468
|
|
|
|
| |
llvm-svn: 334467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When built against the old libc++ version the test was causing linker error
Undefined symbols for architecture x86_64:
"std::experimental::fundamentals_v1::pmr::new_delete_resource()", referenced from:
void test_evil<WidgetV0, WidgetV0>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV0, WidgetV1>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV0, WidgetV2>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV0, WidgetV3>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV1, WidgetV0>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV1, WidgetV1>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV1, WidgetV2>() in construct_piecewise_pair_evil.pass.cpp.o
...
llvm-svn: 334431
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch from Arthur O'Dwyer.
`__user_alloc_construct_impl` is used by <experimental/memory_resource>, but
this `__user_alloc_construct` is never used.
Also, `<experimental/memory_resource>` doesn't need a full definition of
`std::tuple`; just the forward declaration in `<__tuple>` will suffice.
Reviewed as https://reviews.llvm.org/D46806
llvm-svn: 334069
|
|
|
|
| |
llvm-svn: 334056
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++2a[container.requirements.general]p8 states that when move constructing
a container, the allocator is move constructed. Vector previously copy
constructed these allocators. This patch fixes that bug.
Additionally it cleans up some unnecessary allocator conversions
when copy constructing containers. Libc++ uses
__internal_allocator_traits::select_on_copy_construction to select
the correct allocator during copy construction, but it unnecessarily
converted the resulting allocator to the user specified allocator
type and back. After this patch list and forward_list no longer
do that.
Technically we're supposed to be using allocator_traits<allocator_type>::select_on_copy_construction,
but that should seemingly be addressed as a separate patch, if at all.
llvm-svn: 334053
|
|
|
|
|
|
|
|
|
|
|
|
| |
These containers type-punned between pair<K, V> and pair<const K, V> as an
optimization. This commit instead provides access to the pair via a pair of
references that assign through to the underlying object. It's still undefined to
mutate a const object, but clang doesn't optimize on this for data members, so
this should be safe.
Differential revision: https://reviews.llvm.org/D47607
llvm-svn: 333948
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
C++11 onwards specs the non-member functions atomic_load and atomic_load_explicit as taking the atomic<T> by const (potentially volatile) pointer. C11, in its infinite wisdom, decided to drop the const, and C17 will fix this with DR459 (the current draft forgot to fix B.16, but that’s not the normative part).
This patch fixes the libc++ version of the __c11_atomic_load builtins defined for GCC's compatibility sake.
D47618 takes care of the clang side.
Discussion: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058129.html
<rdar://problem/27426936>
Reviewers: EricWF, mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47613
llvm-svn: 333776
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The filesystem test was confused about access versus write / modification time. The spec says:
file_time_type last_write_time(const path& p, error_code& ec) noexcept;
Returns: The time of last data modification of p, determined as if by the value of the POSIX stat structure member st_mtime obtained as if by POSIX stat(). The signature with argument ec returns file_time_type::min() if an error occurs.
The test was looking at st_atime, not st_mtime, when comparing the result from last_write_time. That was probably due to using a pair instead of naming things nicely or using types. I opted to rename things so it's clearer.
This used to cause test bot failures.
<rdar://problem/40648859>
Reviewers: EricWF, mclow.lists, aemerson
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47557
llvm-svn: 333723
|
|
|
|
|
|
|
|
| |
r333467 updated the symbols exported by libc++.so/dylib by changing
the ODR usage of __uncaught_exception/__uncaught_exceptions. This
should not be a breaking change.
llvm-svn: 333481
|
|
|
|
|
|
|
| |
As discussed here: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058116.html
The tests fail on clang-5, as well as apple-clang-9. Mark them as such.
llvm-svn: 333479
|
|
|
|
|
|
| |
this. Thanks to Peter Klotz for calling my attention to this.
llvm-svn: 333467
|
|
|
|
|
|
| |
catch block and call to terminate in string's move assignment. Thanks to Howard for the 'catch'.
llvm-svn: 333435
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch from Arthur O'Dwyer.
In the TS, `uses_allocator` construction for `pair` tried to use an allocator
type of `memory_resource*`, which is incorrect because `memory_resource*` is
not an allocator type. LWG 2969 fixed it to use `polymorphic_allocator` as the
allocator type instead.
https://wg21.link/lwg2969
(D47090 included this in `<memory_resource>`; at Eric's request, I've split
this out into its own patch applied to the existing
`<experimental/memory_resource>` instead.)
Reviewed as https://reviews.llvm.org/D47109
llvm-svn: 333384
|
|
|
|
|
|
| |
template deduction guides - specifically for copy-ctors
llvm-svn: 333381
|
|
|
|
|
|
| |
deduces the wrong type.
llvm-svn: 333376
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That's r333325, as well as follow-up "Fix GCC handling of ATOMIC_VAR_INIT"
r333327.
Marshall asked to revert:
Let's have a discussion about how to implement this so that it is more friendly
to people with installed code bases. We've had *extremely* loud responses to
unilaterally adding warnings - especially ones that can't be easily disabled -
to the libc++ code base in the past.
llvm-svn: 333351
|
|
|
|
|
|
| |
r333325 from D47225 added warning checks, and the test was written to be C++11 correct by using ATOMIC_VAR_INIT (note that the committee fixed that recently...). It seems like GCC can't handle ATOMIC_VAR_INIT well because it generates 'type 'std::atomic<int>' cannot be initialized with an initializer list' on bot libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03. Drop the ATOMIC_VAR_INITs since they weren't required to test the diagnostics.
llvm-svn: 333327
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The atomic non-member functions accept pointers to std::atomic / std::atomic_flag as well as to the non-atomic value. These are all dereferenced unconditionally when lowered, and therefore will fault if null. It's a tiny gotcha for new users, especially when they pass in NULL as expected value (instead of passing a pointer to a NULL value). We can therefore use the nonnull attribute to denote that:
- A warning should be generated if the argument is null
- It is undefined behavior if the argument is null (because a dereference will segfault)
This patch adds support for this attribute for clang and GCC, and sticks to the subset of the syntax both supports. In particular, work around this GCC oddity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60625
The attributes are documented:
- https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html
- https://clang.llvm.org/docs/AttributeReference.html#nullability-attributes
I'm authoring a companion clang patch for the __c11_* and __atomic_* builtins, which currently only warn on a subset of the pointer parameters.
In all cases the check needs to be explicit and not use the empty nonnull list, because some of the overloads are for atomic<T*> and the values themselves are allowed to be null.
<rdar://problem/18473124>
Reviewers: arphaman, EricWF
Subscribers: aheejin, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47225
llvm-svn: 333325
|
|
|
|
|
|
| |
It seems GCC and clang disagree. Talked to mclow on IRC, disabling for now.
llvm-svn: 333317
|
|
|
|
|
|
| |
No matching constructor
llvm-svn: 333315
|
|
|
|
| |
llvm-svn: 333308
|
|
|
|
| |
llvm-svn: 333252
|
|
|
|
| |
llvm-svn: 333251
|
|
|
|
|
|
|
|
| |
if the compiler is not clang.
gcc doesn't allow using __fp16 on non-ARM targets.
llvm-svn: 333108
|
|
|
|
|
|
|
|
| |
floating-point types.
rdar://problem/40377353
llvm-svn: 333103
|
|
|
|
| |
llvm-svn: 333058
|
|
|
|
| |
llvm-svn: 333050
|
|
|
|
| |
llvm-svn: 333011
|
|
|
|
|
|
| |
deallocate -> __vdeallocate. NFC. This change triggered by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61806, which shows up when we implement deduction guides for the container adaptors.The names have a 'v' in them because WIN32 has a macro named __deallocate. (sigh).
llvm-svn: 332996
|
|
|
|
| |
llvm-svn: 332931
|
|
|
|
| |
llvm-svn: 332927
|
|
|
|
| |
llvm-svn: 332901
|
|
|
|
| |
llvm-svn: 332818
|
|
|
|
| |
llvm-svn: 332811
|
|
|
|
|
|
| |
int/long are the same size
llvm-svn: 332797
|
|
|
|
| |
llvm-svn: 332785
|
|
|
|
| |
llvm-svn: 332779
|
|
|
|
|
|
| |
https://reviews.llvm.org/D46964
llvm-svn: 332768
|
|
|
|
|
|
| |
test/std/numerics/rand/rand.eng/rand.eng.lcong/default.pass.cpp
llvm-svn: 332571
|
|
|
|
| |
llvm-svn: 332567
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some *_l functions were not available in some versions of Bionic. This CL
checks that the NDK version supports the functions, and if not, falls back
on the corresponding functions that don't take a locale.
Patch by Tom Anderson!
Differential Revision: https://reviews.llvm.org/D46558
llvm-svn: 332543
|