summaryrefslogtreecommitdiffstats
path: root/libcxx/test/std/thread
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Take 2: Implement LWG 2510Louis Dionne2019-09-262-5/+38
| | | | | | | | | | | | | | | | | | | | | | | 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-upsIlya Biryukov2019-09-252-38/+5
| | | | | | | | | | | | 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 suiteLouis Dionne2019-09-241-1/+1
| | | | | | | 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 olderLouis Dionne2019-09-241-1/+4
| | | | llvm-svn: 372782
* [libc++] Implement LWG 2510Louis Dionne2019-09-242-5/+35
| | | | | | | | | | | | | | | | | | | 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 ↵Dan Albert2019-09-181-11/+22
| | | | | | | | | | pthread_cond_clockwait() where available"" With the fix for non-Linux. This reverts commit c1c519d2f1a66dd2eeaa4c321d8d7b50f623eb71. llvm-svn: 372242
* Revert "Implement std::condition_variable via pthread_cond_clockwait() where ↵Dan Albert2019-09-161-22/+11
| | | | | | | | available" This reverts commit 5e37d7f9ff257ec62d733d3d94b11f03e0fe51ca. llvm-svn: 372034
* Implement std::condition_variable via pthread_cond_clockwait() where availableDan Albert2019-09-161-11/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.<Paste> llvm-svn: 372016
* libcxx: Rename .hpp files in libcxx/test/support to .hNico Weber2019-08-219-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.Nico Weber2019-07-301-1/+3
| | | | | | | | | | | | | | | | | | | [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
* Fix PR27658 - Make ~mutex trivial when possible.Eric Fiselier2019-07-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently std::mutex has a constexpr constructor, but a non-trivial destruction. The constexpr constructor is required to ensure the construction of a mutex with static storage duration happens at compile time, during constant initialization, and not during dynamic initialization. This means that static mutex's are always initialized and can be used safely during dynamic initialization without the "static initialization order fiasco". A trivial destructor is important for similar reasons. If a mutex is used during dynamic initialization it might also be used during program termination. If a static mutex has a non-trivial destructor it will be invoked during termination. This can introduce the "static deinitialization order fiasco". Additionally, function-local statics emit a guard variable around non-trivially destructible types. This results in horrible codegen and adds a runtime cost to every call to that function. non-local static's also result in slightly worse codegen but it's not as big of a problem. Example codegen can be found here: https://goo.gl/3CSzbM Note: This optimization is not safe with every pthread implementation. Some implementations allocate on the first call to pthread_mutex_lock and free the allocation in pthread_mutex_destroy. Also, changing the triviality of the destructor is not an ABI break. At least to the best of my knowledge :-) llvm-svn: 365273
* Add include for 'test_macros.h' to all the tests that were missing them. ↵Marshall Clow2019-05-31144-0/+281
| | | | | | Thanks to Zoe for the (big, but simple) patch. NFC intended. llvm-svn: 362252
* [libc++][test] Remove non-portable assumption that thread's constructor ↵Casey Carter2019-05-021-10/+19
| | | | | | | | | | | | | allocates with ::new Drive-by: * Fix potential race between check and update of `throw_one` in `operator new` * Fix latent bug in `operator delete`, which shouldn't decrement `outstanding_new` when passed a null pointer * Specifically catch the expected `bad_alloc` in `main` instead of `...` Differential Revision: https://reviews.llvm.org/D50860 llvm-svn: 359827
* [libc++] Remove unnecessary <iostream> #includes in testsLouis Dionne2019-03-284-8/+0
| | | | | | | Some tests #include <iostream> but they don't use anything from the header. Those are probably artifacts of when the tests were developped. llvm-svn: 357181
* [libc++] Add proper XFAILs for shared_mutex testsLouis Dionne2019-03-2714-2/+13
| | | | | | | | | | Dylib support for shared_mutex was added in macOS 10.12, so the tests should be XFAILed accordingly instead of being completely disabled whenever availability is enabled. rdar://problem/48769104 llvm-svn: 357079
* Mark another test as flakyKamil Rytarowski2019-02-091-0/+2
| | | | | | Reported on the NetBSD buildbot. llvm-svn: 353622
* Support tests in freestandingJF Bastien2019-02-04260-260/+779
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Freestanding is *weird*. The standard allows it to differ in a bunch of odd manners from regular C++, and the committee would like to improve that situation. I'd like to make libc++ behave better with what freestanding should be, so that it can be a tool we use in improving the standard. To do that we need to try stuff out, both with "freestanding the language mode" and "freestanding the library subset". Let's start with the super basic: run the libc++ tests in freestanding, using clang as the compiler, and see what works. The easiest hack to do this: In utils/libcxx/test/config.py add: self.cxx.compile_flags += ['-ffreestanding'] Run the tests and they all fail. Why? Because in freestanding `main` isn't special. This "not special" property has two effects: main doesn't get mangled, and main isn't allowed to omit its `return` statement. The first means main gets mangled and the linker can't create a valid executable for us to test. The second means we spew out warnings (ew) and the compiler doesn't insert the `return` we omitted, and main just falls of the end and does whatever undefined behavior (if you're luck, ud2 leading to non-zero return code). Let's start my work with the basics. This patch changes all libc++ tests to declare `main` as `int main(int, char**` so it mangles consistently (enabling us to declare another `extern "C"` main for freestanding which calls the mangled one), and adds `return 0;` to all places where it was missing. This touches 6124 files, and I apologize. The former was done with The Magic Of Sed. The later was done with a (not quite correct but decent) clang tool: https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed This works for most tests, though I did have to adjust a few places when e.g. the test runs with `-x c`, macros are used for main (such as for the filesystem tests), etc. Once this is in we can create a freestanding bot which will prevent further regressions. After that, we can start the real work of supporting C++ freestanding fairly well in libc++. <rdar://problem/47754795> Reviewers: ldionne, mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits Differential Revision: https://reviews.llvm.org/D57624 llvm-svn: 353086
* Mark another test as flakyKamil Rytarowski2019-01-241-0/+2
| | | | | | Reported on the NetBSD 8 buildbot. llvm-svn: 352064
* Mark another test as flakyKamil Rytarowski2019-01-231-0/+2
| | | | | | Reported on the NetBSD 8 buildbot. llvm-svn: 351995
* Mark another test as flakyKamil Rytarowski2019-01-231-0/+2
| | | | | | Reported on the NetBSD 8 buildbot. llvm-svn: 351988
* Correct mark for flaky testsKamil Rytarowski2019-01-237-7/+7
| | | | | | Add missing trailing dot. llvm-svn: 351983
* Mark more tests flakyKamil Rytarowski2019-01-232-0/+4
| | | | | | Reported on the NetBSD 8 buildbot llvm-svn: 351944
* Mark thread.condition.condvarany/wait_for.pass.cpp as flakyKamil Rytarowski2019-01-231-0/+2
| | | | | | Reported on the NetBSD 8 buildbot. llvm-svn: 351937
* Update more file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-19260-1040/+780
| | | | | | | | | | | | | | | | | | to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351648
* Mark two more tests as FLAKYEric Fiselier2019-01-092-0/+4
| | | | llvm-svn: 350692
* Mark more tests as flakyEric Fiselier2019-01-075-0/+10
| | | | llvm-svn: 350550
* [libcxx] Make UNSUPPORTED for std::async test more fine grainedLouis Dionne2018-11-291-1/+8
| | | | | | | | The test was previously marked as unsupported on all Apple platforms, when we really just want to mark it as unsupported for previously shipped dylibs on macosx. llvm-svn: 347920
* Repair thread-unsafe modifications of n_alive in F.pass.cppBilly Robert O'Neal III2018-10-191-4/+10
| | | | | | | | In this example, the ctor of G runs in the main thread in the expression G(), and also in the copy ctor of G() in the DECAY_COPY inside std::thread. The main thread destroys the G() instance at the semicolon, and the started thread destroys the G() after it returns. Thus there is a race between the threads on the n_alive variable. The fix is to join with the background thread before attempting to destroy the G in the main thread. llvm-svn: 344820
* [libcxx] Mark std::async race condition test as unsupported on DarwinLouis Dionne2018-10-091-0/+4
| | | | | | | | | | PR38682 added a test to check for a race condition in std::future. Part of the fix is part of the dylib, but there is no released version of mac OS X that ships a dylib containing the fix. Hence, this test can (and sometimes does) when testing on OS X. This commit marks the test as unsupported to avoid spurious failures. llvm-svn: 344053
* Mork more tests as FLAKYEric Fiselier2018-10-012-1/+2
| | | | llvm-svn: 343435
* Mark test as flakyEric Fiselier2018-09-221-0/+2
| | | | llvm-svn: 342818
* [libc++] Remove race condition in std::asyncLouis Dionne2018-08-241-0/+58
| | | | | | | | | | | | | | | | | Summary: The state associated to the future was set in one thread (with synchronization) but read in another thread without synchronization, which led to a data race. https://bugs.llvm.org/show_bug.cgi?id=38181 rdar://problem/42548261 Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D51170 llvm-svn: 340608
* [libcxx] [test] Fix whitespace, NFC.Stephan T. Lavavej2018-04-121-3/+3
| | | | | | test/std almost always uses spaces; now it is entirely tab-free. llvm-svn: 329978
* Revert commit removing allocator support from packaged_task. Will ↵Marshall Clow2017-11-272-0/+37
| | | | | | investigate further llvm-svn: 319091
* Implement LWG#2921 and LWG#2976 - removing allocator support from packaged_task.Marshall Clow2017-11-272-37/+0
| | | | llvm-svn: 319080
* Add additional 'UNSUPPORTED' to the test case.Marshall Clow2017-11-231-1/+2
| | | | llvm-svn: 318897
* Add [[nodiscard]] to std::async as part of P0600.Marshall Clow2017-11-231-0/+37
| | | | llvm-svn: 318889
* Change (void) casts to TEST_IGNORE_NODISCARD, as requested by Eric. Reviewed ↵Billy Robert O'Neal III2017-11-216-12/+12
| | | | | | as https://reviews.llvm.org/D40065 llvm-svn: 318804
* Tolerate even more [[nodiscard]] in the STL. Reviewed as ↵Billy Robert O'Neal III2017-11-157-27/+27
| | | | | | https://reviews.llvm.org/D39080 llvm-svn: 318277
* Placate unused variable warnings uncovered by improvements to clang's ↵Benjamin Kramer2017-10-141-0/+2
| | | | | | -Wunused-variable llvm-svn: 315809
* [libcxx] [test] Update for C++17 feature removals.Stephan T. Lavavej2017-08-242-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | test/std/containers/Emplaceable.h test/std/containers/NotConstructible.h test/support/counting_predicates.hpp Replace unary_function/binary_function inheritance with typedefs. test/std/depr/depr.function.objects/depr.base/binary_function.pass.cpp test/std/depr/depr.function.objects/depr.base/unary_function.pass.cpp test/std/utilities/function.objects/func.require/binary_function.pass.cpp test/std/utilities/function.objects/func.require/unary_function.pass.cpp Mark these tests as requiring 98/03/11/14 because 17 removed unary_function/binary_function. test/std/thread/futures/futures.task/futures.task.members/ctor_func_alloc.pass.cpp test/std/thread/futures/futures.task/futures.task.nonmembers/uses_allocator.pass.cpp Mark these tests as requiring 11/14 because 17 removed packaged_task allocator support. test/std/utilities/function.objects/func.wrap/func.wrap.func/derive_from.pass.cpp This test doesn't need to be skipped in C++17 mode. Only the construction of std::function from an allocator needs to be skipped in C++17 mode. test/std/utilities/function.objects/refwrap/refwrap.access/conversion.pass.cpp test/std/utilities/function.objects/refwrap/refwrap.assign/copy_assign.pass.cpp test/std/utilities/function.objects/refwrap/refwrap.const/copy_ctor.pass.cpp test/std/utilities/function.objects/refwrap/refwrap.const/type_ctor.pass.cpp When testing these reference_wrapper features, unary_function inheritance is totally irrelevant. test/std/utilities/function.objects/refwrap/weak_result.pass.cpp Define and use my_unary_function/my_binary_function to test the weak result type machinery (which is still present in C++17, although deprecated). test/support/msvc_stdlib_force_include.hpp Now we can test C++17 strictly, without enabling removed features. Fixes D36503. llvm-svn: 311705
* [libcxx] [test] Fix URLs in comments and make them HTTPS. NFC.Stephan T. Lavavej2017-08-051-1/+1
| | | | llvm-svn: 310156
* [libcxx] [test] Consistently list "c++98, c++03" in chronological order. NFC.Stephan T. Lavavej2017-08-0515-15/+15
| | | | llvm-svn: 310155
* [libcxx] [test] The entire file futures.shared_future/wait_until.pass.cpp ↵Stephan T. Lavavej2017-07-291-130/+130
| | | | | | was indented by 1 space. NFC. llvm-svn: 309467
* [libcxx] [test] Untabify, NFC.Stephan T. Lavavej2017-07-294-11/+11
| | | | llvm-svn: 309464
* Implement P0739R0: 'Some improvements to class template argument deduction ↵Marshall Clow2017-07-271-4/+4
| | | | | | integration into the standard library' This is an API change (not ABI change) due to a late change in the c++17 standard llvm-svn: 309296
* [libcxx] [test] Fix Clang -Wunused-local-typedef warnings.Stephan T. Lavavej2017-07-191-1/+0
| | | | | | Fix D34536. llvm-svn: 308534
* Fix diagnostic in verify test to match new Clang outputEric Fiselier2017-07-071-1/+1
| | | | llvm-svn: 307450
* Fix compile error with Bionic's PTHREAD_MUTEX_INITIALIZEREric Fiselier2017-06-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | On Bionic PTHREAD_MUTEX_INITIALIZER contains the expression "<enum-type> & <integer-type>", which causes ADL to perform name lookup for operator&. During this lookup Clang decides that it requires the default member initializer for std::mutex while defining the DMI for std::mutex::__m_. If I'm not mistaken this is caused by the explicit noexcept declaration on the defaulted constructor. This patch removes the explicit noexcept and instead allows the compiler to declare the default constructor implicitly noexcept. It also adds a static_assert to ensure that happens. Unfortunatly because it's not easy to change the value of _LIBCPP_MUTEX_INITIALIZER for a single test there is no good way to test this patch. The Clang behavior causing the trouble here was introduced in r287713, which first appears in the 4.0 release. llvm-svn: 304942
* Move POSIX specific test under test/libcxx subdirectoryEric Fiselier2017-05-121-76/+0
| | | | llvm-svn: 302865
OpenPOWER on IntegriCloud