run_tests.py had bitrotted since it was last run (e.g. it used perl
which is now not allowed and the warning flags were out of date).
I changed it to use a different way of extracting the compile command
which is based on Soong instead of makefiles. This way is also
compatible with multiple build directories since it doesn't clobber
the source directory and doesn't require OUT_DIR == out.
This also changes run_tests.py to run the libcxxabi tests as well,
since they can be run using the same mechanism.
Bug: 120510768
Test: ./run_tests.py --bitness 32
Test: ./run_tests.py --bitness 64
Test: ./run_tests.py --bitness 64 --host
Change-Id: Id30129161f8519fa6c1bc106727326373ca9ab82
- Use Win32 threads. MinGW pthreads throws an error when building
libcxx since it's pthread_mutex_initializer is not constant (needs a
cast).
- Disable visibility annotations for libcxx and libcxxabi since we are
only going to support these as static libraries.
- Build sources for Windows platform support.
- Use SjLj exceptions for 32-bit. libgcc_eh implements SjLj exception
model for 32-bit.
- Undefine WIN32_LEAN_AND_MEAN macro. libcxx sources define them where
necessary.
Test: Build and test Windows binaries under Wine.
Change-Id: I76a440ff5d71eb5a3b7d57dd97e742a458ffbe16
Summary:
_is_chartype_l (needed for isxdigit_l) in MinGW compares locale_t and NULL.
NULL is 'long long' for 64-bit, and this results in ambiguous overloads when
compiled with Clang. Define a concrete overload for the operators to fix the
ambiguity.
Reviewers: mstorsjo, EricWF, srhines, danalbert
Subscribers: christof, cfe-commits, ldionne
Differential Revision: https://reviews.llvm.org/D48749
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@336141 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Use _LIBCPP_MSVCRT_LIKE while configuring ELAST, so MinGW gets the same
configuration as MSVC.
Reviewers: compnerd, srhines, danalbert, mstorsjo
Subscribers: christof, ldionne, cfe-commits
Differential Revision: https://reviews.llvm.org/D48731
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@335916 91177308-0d34-0410-b5e6-96231b3b80d8
The Chrome folks are trying to build libc++ with an old NDK and added
checks to handle that, but we don't have <android/ndk-version.h> in
the platform.
Test: make checkbuild
Bug: None
Change-Id: Ic28bd67ecee1a93b47ce0b307415c3ff25b449eb
This resolves the breakage introduced in r334468 which results in
build error when using CMake Makefile generator.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@334470 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@334468 91177308-0d34-0410-b5e6-96231b3b80d8
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
...
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@334431 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@334069 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@334053 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333948 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333776 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333723 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333481 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333384 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333351 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333327 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@333325 91177308-0d34-0410-b5e6-96231b3b80d8
