bcm5719-llvm/libcxx/test/std/thread, branch meklort-10.0.1

[libc++] Take 2: Implement LWG 2510

2019-09-26T14:51:10+00:00

Summary: LWG2510 makes tag types like allocator_arg_t explicitly default constructible instead of implicitly default constructible. It also makes the constructors for std::pair and std::tuple conditionally explicit based on the explicit-ness of the default constructibility for the pair/tuple's elements. This was previously committed as r372777 and reverted in r372832 due to the commit breaking LLVM's build in C++14 mode. This issue has now been addressed. Reviewers: mclow.lists Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D65161 llvm-svn: 372983

Revert r372777: [libc++] Implement LWG 2510 and its follow-ups

2019-09-25T09:10:38+00:00

This also reverts: - r372778: [libc++] Implement LWG 3158 - r372782: [libc++] Try fixing tests that fail on GCC 5 and older - r372787: Purge mentions of GCC 4 from the test suite Reason: the change breaks compilation of LLVM with libc++, for details see http://lists.llvm.org/pipermail/libcxx-dev/2019-September/000599.html llvm-svn: 372832

[libc++] Purge mentions of GCC 4 from the test suite

2019-09-24T22:42:36+00:00

We don't support GCC 4 and older according to the documentation, so we should pretend it doesn't exist. llvm-svn: 372787

[libc++] Try fixing tests that fail on GCC 5 and older

2019-09-24T22:13:17+00:00

llvm-svn: 372782

[libc++] Implement LWG 2510

2019-09-24T20:18:54+00:00

Summary: LWG2510 makes tag types like allocator_arg_t explicitly default constructible instead of implicitly default constructible. It also makes the constructors for std::pair and std::tuple conditionally explicit based on the explicit-ness of the default constructibility for the pair/tuple's elements. Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D65161 llvm-svn: 372777

Revert "Revert "Implement std::condition_variable via pthread_cond_clockwait() where available""

2019-09-18T18:13:32+00:00

With the fix for non-Linux. This reverts commit c1c519d2f1a66dd2eeaa4c321d8d7b50f623eb71. llvm-svn: 372242

Revert "Implement std::condition_variable via pthread_cond_clockwait() where available"

2019-09-16T21:20:32+00:00

This reverts commit 5e37d7f9ff257ec62d733d3d94b11f03e0fe51ca. llvm-svn: 372034

Implement std::condition_variable via pthread_cond_clockwait() where available

2019-09-16T17:57:48+00:00

std::condition_variable is currently implemented via pthread_cond_timedwait() on systems that use pthread. This is problematic, since that function waits by default on CLOCK_REALTIME and libc++ does not provide any mechanism to change from this default. Due to this, regardless of if condition_variable::wait_until() is called with a chrono::system_clock or chrono::steady_clock parameter, condition_variable::wait_until() will wait using CLOCK_REALTIME. This is not accurate to the C++ standard as calling condition_variable::wait_until() with a chrono::steady_clock parameter should use CLOCK_MONOTONIC. This is particularly problematic because CLOCK_REALTIME is a bad choice as it is subject to discontinuous time adjustments, that may cause condition_variable::wait_until() to immediately timeout or wait indefinitely. This change fixes this issue with a new POSIX function, pthread_cond_clockwait() proposed on http://austingroupbugs.net/view.php?id=1216. The new function is similar to pthread_cond_timedwait() with the addition of a clock parameter that allows it to wait using either CLOCK_REALTIME or CLOCK_MONOTONIC, thus allowing condition_variable::wait_until() to wait using CLOCK_REALTIME for chrono::system_clock and CLOCK_MONOTONIC for chrono::steady_clock. pthread_cond_clockwait() is implemented in glibc (2.30 and later) and Android's bionic (Android API version 30 and later). This change additionally makes wait_for() and wait_until() with clocks other than chrono::system_clock use CLOCK_MONOTONIC. llvm-svn: 372016

libcxx: Rename .hpp files in libcxx/test/support to .h

2019-08-21T00:14:12+00:00

LLVM uses .h as its extension for header files. Files renamed using: for f in libcxx/test/support/*.hpp; do git mv $f ${f%.hpp}.h; done References to the files updated using: for f in $(git diff master | grep 'rename from' | cut -f 3 -d ' '); do a=$(basename $f); echo $a; rg -l $a libcxx | xargs sed -i '' "s/$a/${a%.hpp}.h/"; done HPP include guards updated manually using: for f in $(git diff master | grep 'rename from' | cut -f 3 -d ' '); do echo ${f%.hpp}.h ; done | xargs mvim Differential Revision: https://reviews.llvm.org/D66104 llvm-svn: 369481

libcxx: Define __STDCPP_THREADS to 1, not to cplusplus.

2019-07-30T14:32:47+00:00

[cpp.predefined]p2: __STDCPP_THREADS__ Defined, and has the value integer literal 1, if and only if a program can have more than one thread of execution . Also define it only if it's not defined already, since it's supposed to be defined by the compiler. Also move it from thread to __config (which requires setting it only if _LIBCPP_HAS_NO_THREADS is not defined). Part of PR33230. The intent is to eventually make the compiler define this instead. llvm-svn: 367316