summaryrefslogtreecommitdiffstats
path: root/libcxx/test/std/thread/thread.mutex/thread.mutex.requirements
Commit message (Collapse)AuthorAgeFilesLines
* 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-3122-0/+44
| | | | | | Thanks to Zoe for the (big, but simple) patch. NFC intended. llvm-svn: 362252
* [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
* Mark another test as flakyKamil Rytarowski2019-02-091-0/+2
| | | | | | Reported on the NetBSD buildbot. llvm-svn: 353622
* Support tests in freestandingJF Bastien2019-02-0449-49/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update more file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1949-196/+147
| | | | | | | | | | | | | | | | | | 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
* [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