summaryrefslogtreecommitdiffstats
path: root/libcxx/test/std/thread/thread.mutex/thread.mutex.requirements
Commit message (Collapse)AuthorAgeFilesLines
* [libcxx] [test] Consistently list "c++98, c++03" in chronological order. NFC.Stephan T. Lavavej2017-08-0515-15/+15
| | | | llvm-svn: 310155
* 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
* Add markup for libc++ dylib availabilityMehdi Amini2017-05-042-0/+4
| | | | | | | | | | | | | | | Libc++ is used as a system library on macOS and iOS (amongst others). In order for users to be able to compile a binary that is intended to be deployed to an older version of the platform, clang provides the availability attribute <https://clang.llvm.org/docs/AttributeReference.html#availability>_ that can be placed on declarations to describe the lifecycle of a symbol in the library. See docs/DesignDocs/AvailabilityMarkup.rst for more information. Differential Revision: https://reviews.llvm.org/D31739 llvm-svn: 302172
* Adjust libc++ test infastructure to fully support modulesEric Fiselier2016-12-0510-10/+10
| | | | | | | | | | | | This patch overhalls the libc++ test format/configuration in order to fully support modules. By "fully support" I mean get almost all of the tests passing. The main hurdle for doing this is handling tests that `#define _LIBCPP_FOO` macros to test a different configuration. This patch deals with these tests in the following ways: 1. For tests that define single `_LIBCPP_ABI_FOO` macros have been annotated with `// MODULES_DEFINES: _LIBCPP_ABI_FOO`. This allows the test suite to define the macro on the command line so it uses a different set of modules. 2. Tests for libc++'s debug mode (which define custom `_LIBCPP_ASSERT`) are automatically detected by the test suite and are compiled and run with modules disabled. This patch also cleans up how the `CXXCompiler` helper class handles enabling/disabling language features. NOTE: This patch uses `LIT` features which were only committed to LLVM today. If this patch breaks running the libc++ tests you probably need to update LLVM. llvm-svn: 288728
* Add "FLAKY_TEST" test directive to support re-running flaky tests.Eric Fiselier2016-08-3010-0/+20
| | | | | | | | Some of the mutex tests fail on machines with high load. This patch implements the test directive "// FLAKY_TEST" which allows a test to be run 3 times before it's considered a failure. llvm-svn: 280050
* Move native_handle thread tests to test/libcxxEric Fiselier2016-06-222-54/+0
| | | | llvm-svn: 273341
* [libcxx] Improve tests to use the UNSUPPORTED lit directiveAsiri Rathnayake2016-05-282-8/+2
| | | | | | | | | | | | | | | | | | | Quite a few libcxx tests seem to follow the format: #if _LIBCPP_STD_VER > X // Do test. #else // Empty test. #endif We should instead use the UNSUPPORTED lit directive to exclude the test on earlier C++ standards. This gives us a more accurate number of test passes for those standards and avoids unnecessary conflicts with other lit directives on the same tests. Reviewers: bcraig, ericwf, mclow.lists Differential revision: http://reviews.llvm.org/D20730 llvm-svn: 271108
* Guard a number of tests relying on threads support when built inRichard Barton2016-03-232-0/+2
| | | | | | | | single-threaded mode. Differential Revision: http://reviews.llvm.org/D14731 llvm-svn: 264191
* Attempt to prevent flaky thread.mutex tests by once again increasing timing ↵Eric Fiselier2015-10-018-19/+24
| | | | | | tolerances llvm-svn: 248993
* Refactor flaky shared_mutex testsEric Fiselier2015-08-264-22/+39
| | | | llvm-svn: 246055
* Refactor and fix more flaky shared_mutex testsEric Fiselier2015-08-256-37/+123
| | | | llvm-svn: 245918
* Implement N4508: shared_mutex. Reviewed as http://reviews.llvm.org/D10480Marshall Clow2015-06-308-0/+327
| | | | llvm-svn: 241067
* Change #ifdefs in test to UNSUPPORTED. No functionality change in the testsMarshall Clow2015-06-119-48/+10
| | | | llvm-svn: 239562
* [libcxx] Fix bug in shared_timed_mutex that could cause a program to hang.Eric Fiselier2015-04-021-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The summary of the bug, provided by Stephan T. Lavavej: In shared_timed_mutex::try_lock_until() (line 195 in 3.6.0), you need to deliver a notification. The scenario is: * There are N threads holding the shared lock. * One thread calls try_lock_until() to attempt to acquire the exclusive lock. It sets the "I want to write" bool/bit, then waits for the N readers to drain away. * K more threads attempt to acquire the shared lock, but they notice that someone said "I want to write", so they block on a condition_variable. * At least one of the N readers is stubborn and doesn't release the shared lock. * The wannabe-writer times out, gives up, and unsets the "I want to write" bool/bit. At this point, a notification (it needs to be notify_all) must be delivered to the condition_variable that the K wannabe-readers are waiting on. Otherwise, they can block forever without waking up. Reviewers: mclow.lists, jyasskin Reviewed By: jyasskin Subscribers: jyasskin, cfe-commits Differential Revision: http://reviews.llvm.org/D8796 llvm-svn: 233944
* Move test into test/std subdirectory.Eric Fiselier2014-12-2042-0/+1709
llvm-svn: 224658
OpenPOWER on IntegriCloud