summaryrefslogtreecommitdiffstats
path: root/libcxx/include/__mutex_base
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Ensure __config always defines certain configuration macros.Eric Fiselier2019-12-131-9/+0
|
* [libc++] Take 2: Implement LWG 2510Louis Dionne2019-09-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | 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-251-3/+3
| | | | | | | | | | | | 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++] Implement LWG 2510Louis Dionne2019-09-241-3/+3
| | | | | | | | | | | | | | | | | | | 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-17/+128
| | | | | | | | | | 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-128/+17
| | | | | | | | available" This reverts commit 5e37d7f9ff257ec62d733d3d94b11f03e0fe51ca. llvm-svn: 372034
* Implement std::condition_variable via pthread_cond_clockwait() where availableDan Albert2019-09-161-17/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [libc++] Use [[nodiscard]] for lock_guard, as an extensionLouis Dionne2019-08-131-2/+3
| | | | | | | | | | | | | | | | | | | Summary: D64914 added support for applying [[nodiscard]] to constructors. This commit uses that capability to flag incorrect uses of std::lock_guard where one forgets to actually create a variable for the lock_guard. rdar://45790820 Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits, Quuxplusone, lebedev.ri Tags: #libc Differential Revision: https://reviews.llvm.org/D65900 llvm-svn: 368664
* Revert "Suppress -Wctad-maybe-unsupported on types w/o deduction guides."Eric Fiselier2019-08-041-3/+0
| | | | | | | | | Some modules builds are issuing buggy diagnostics. The cause of which is TBD. This reverts commit r@367770. llvm-svn: 367777
* Suppress -Wctad-maybe-unsupported on types w/o deduction guides.Eric Fiselier2019-08-031-0/+3
| | | | | | | | | | | There are a handful of standard library types that are intended to support CTAD but don't need any explicit deduction guides to do so. This patch adds a dummy deduction guide to those types to suppress -Wctad-maybe-unsupported (which gets emitted in user code). llvm-svn: 367770
* Make ~mutex and ~condition_variable trivial on Windows.Eric Fiselier2019-07-071-13/+7
| | | | | | | | | The implementations of __libcpp_mutex_destroy and __libcpp_condvar_destroy are already NOPs, so this optimization is safe to perform. See r365273 and PR27658 for more information. llvm-svn: 365281
* Fix PR27658 - Make ~mutex trivial when possible.Eric Fiselier2019-07-071-13/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix buildbot failures after r359159.Richard Smith2019-04-251-1/+1
| | | | | | | | | | | | | std::mutex was not actually is_nothrow_default_constructible in C++98/C++03, because the variable declaration std::mutex M; ... could throw an exception from the mutex destructor. Fix it by marking the destructor as non-throwing. This has no effect in C++11 onwards, because destructors are non-throwing by default in those language modes. llvm-svn: 359229
* Update more file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | | 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
* [libc++] Make sure we can build libc++ with -fvisibility=hiddenLouis Dionne2018-10-251-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: When building with -fvisibility=hidden, some symbols do not get exported from libc++.dylib. This means that some entities are not explicitly given default visibility in the source code, and that we rely on the fact -fvisibility=default is the default. This commit explicitly gives default visibility to those symbols to avoid being dependent on the command line flags used. The commit also remove symbols from the dylib -- those symbols do not actually need to be exported from the dylib and this should not be an ABI break. Finally, in the future, we may want to mark the whole std:: namespace as having hidden visibility (to switch from opt-out to opt-in), in which case the changes done in this commit will be required. Reviewers: EricWF Subscribers: mgorny, christof, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D52662 llvm-svn: 345260
* [libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since ↵Louis Dionne2018-08-011-1/+1
| | | | | | | | | | | | | | _LIBCPP_BUILDING_LIBRARY Summary: As suggested by Marshall in https://reviews.llvm.org/D49914 Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50008 llvm-svn: 338475
* One more (should be) inline variable that is defined in the dylibMarshall Clow2018-01-021-3/+3
| | | | llvm-svn: 321666
* Implement most of P0607: Inline Variables for the Standard Library. This ↵Marshall Clow2018-01-021-3/+3
| | | | | | involved marking a lot of variables as inline (but only for C++17 and later). llvm-svn: 321658
* Fix compile error with Bionic's PTHREAD_MUTEX_INITIALIZEREric Fiselier2017-06-071-1/+4
| | | | | | | | | | | | | | | | | | | | | | 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
* [Libc++] Use #pragma push_macro/pop_macro to better handle min/max on WindowsEric Fiselier2017-05-311-1/+7
| | | | | | | | | | | | | | | | Summary: This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning. This patch changes libc++ to use `#pragma push_macro` to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header. Reviewers: mclow.lists, bcraig, compnerd, EricWF Reviewed By: EricWF Subscribers: cfe-commits, krytarowski Differential Revision: https://reviews.llvm.org/D33080 llvm-svn: 304357
* [libc++] Refactor Windows support headers.Eric Fiselier2017-05-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch refactors and tries to remove as much of the Windows support headers as possible. This is needed because they currently introduce super weird include cycles and dependencies between STL and libc headers. The changes in this patch are: * remove `support/win32/support.h` completely. The required parts have either been moved into `support/win32/msvc_support.h` (for `MSVC` only helpers not needed by Clang), or directly into their respective `foo.h` headers. * Combine `locale_win32.h` and `locale_mgmt_win32.h` into a single headers, this header should only be included within `__locale` or `locale` to avoid include cycles. * Remove the unneeded parts of `limits_win32.h` and re-name it to `limits_msvc_win32.h` since it's only needed by Clang. I've tested this patch using Clang on Windows, but I suspect it might technically regress our non-existent support for MSVC. Is somebody able to double check? This refactor is needed to support upcoming fixes to `<locale>` on Windows. Reviewers: bcraig, rmaprath, compnerd, EricWF Reviewed By: EricWF Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D32988 llvm-svn: 302727
* Cleanup _LIBCPP_HAS_NO_<c++11-feature> macros in thread.Eric Fiselier2017-04-181-7/+7
| | | | llvm-svn: 300622
* Implement Pp0156r2: 'Variadic Lock Guard, version 5' Reviewed as ↵Marshall Clow2017-03-241-12/+0
| | | | | | https://reviews.llvm.org/D31163. llvm-svn: 298681
* [libc++] Make _LIBCPP_TYPE_VIS export membersShoaib Meenai2017-03-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most classes annotated with _LIBCPP_TYPE_VIS need to have at least some of their members exported, otherwise we have a lot of link errors when linking against a libc++ built with hidden visibility. This also makes _LIBCPP_TYPE_VIS be consistent across platforms, since on Windows it already exports members. With this change made, any template methods of a class marked _LIBCPP_TYPE_VIS will also get default visibility when instantiatied, which is not desirable for clients of libc++ headers who wish to control their visibility; this is the same issue as PR30642. Annotate all problematic methods with an explicit visibility specifier to avoid this. The problematic methods were found by running bad-visibility-finder [1] against the libc++ headers after making the _LIBCPP_TYPE_VIS change. The small methods were marked for inlining; the larger ones hidden. [1] https://github.com/smeenai/bad-visibility-finder Reviewers: mclow.lists, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25208 llvm-svn: 296732
* Swap two lines in __mutex_base. On systems with high clock rates, we could ↵Marshall Clow2017-01-091-1/+1
| | | | | | mistakenly return no_timeout when a mutex had timed out if we got a tick between these two lines. Thanks to Brian Cain for the bug report. llvm-svn: 291492
* [NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VISEric Fiselier2017-01-041-3/+3
| | | | | | | | | | | | | The name _LIBCPP_TYPE_VIS_ONLY is no longer accurate because both _LIBCPP_TYPE_VIS and _LIBCPP_TYPE_VIS_ONLY expand to __attribute__((__type_visibility__)) with Clang. The only remaining difference is that _LIBCPP_TYPE_VIS_ONLY can be applied to templates whereas _LIBCPP_TYPE_VIS cannot (due to dllimport/dllexport not being allowed on templates). This patch renames _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS. llvm-svn: 291035
* Remove _LIBCPP_HAS_NO_DEFAULTED_FUNCTIONSEric Fiselier2016-11-181-2/+2
| | | | | | | | libc++ no longer supports C++11 compilers that don't implement `= default`. This patch removes all instances of the feature test macro _LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS as well as the potentially dead code it hides. llvm-svn: 287321
* Don't use pthread initializers in constexpr constructors. Patch by elram. ↵Marshall Clow2016-07-181-5/+14
| | | | | | Reviewed at https://reviews.llvm.org/D21637. llvm-svn: 275819
* Implement variadic lock_guard.Eric Fiselier2016-06-141-3/+16
| | | | | | | | | | | | | | | | | | | | Summary: This patch implements the variadic `lock_guard` paper. Making `lock_guard` variadic is a ABI breaking change because the specialization `lock_guard<_Mutex>` mangles differently then when it was the primary template. This change only provides variadic `lock_guard` in ABI V2 or when `_LIBCPP_ABI_VARIADIC_LOCK_GUARD` is defined. Note that in ABI V2 `lock_guard` must always be declared as a variadic template, even in C++03, in order to keep the ABI consistent. For this reason `lock_guard` is forward declared as a variadic template in all standard dialects and therefore depends on variadic templates being provided as an extension in C++03. All supported versions of Clang and GCC provide this extension. Reviewers: mclow.lists Subscribers: K-ballo, mclow.lists, cfe-commits Differential Revision: http://reviews.llvm.org/D21260 llvm-svn: 272634
* Refactor pthread usage of libcxx.Asiri Rathnayake2016-05-061-11/+9
| | | | | | | | | | | | | This patch extracts out all the pthread dependencies of libcxx into the new header __threading_support. The motivation is to make it easy to re-target libcxx into platforms that do not support pthread. Original patch from Fulvio Esposito (fulvio.esposito@outlook.com) - D11781 Applied with tweaks - D19412 Change-Id: I301111f0075de93dd8129416e06babc195aa936b llvm-svn: 268734
* Qualify calls to addressof to avoid getting ADL. Fixes PR#27254.Marshall Clow2016-04-131-6/+6
| | | | llvm-svn: 266209
* Add clang thread safety annotations to mutex and lock_guard. Patch by ↵Eric Fiselier2016-03-161-8/+16
| | | | | | | | | | | | | | | jamesr@google.com. This adds clang thread safety annotations to std::mutex and std::lock_guard so code using these types can use these types directly instead of having to wrap the types to provide annotations. These checks when enabled by -Wthread-safety provide simple but useful static checking to detect potential race conditions. See http://clang.llvm.org/docs/ThreadSafetyAnalysis.html for details. This patch was reviewed in http://reviews.llvm.org/D14731. llvm-svn: 263611
* Implement LWG2577: {shared,unique}_lock</tt> should use std::addressofMarshall Clow2016-03-141-6/+6
| | | | llvm-svn: 263506
* Cleanup: move visibility/linkage attributes to the first declaration.Evgeniy Stepanov2015-11-071-1/+2
| | | | | | | | | | | | This change moves visibility attributes from out-of-class method definitions to in-class declaration. This is needed for a switch to attribute((internal_linkage)) (see http://reviews.llvm.org/D13925) which can only appear on the first declaration. This change does not touch istream/ostream/streambuf. They are handled separately in http://reviews.llvm.org/D14409. llvm-svn: 252385
* Do not include pthread.h and sched.h when threads are disabledJonathan Roelofs2015-08-271-0/+2
| | | | | | | | Patch by Philippe Daouadi! http://reviews.llvm.org/D9639 llvm-svn: 246168
* Allow libc++ to be built on systems without POSIX threadsJonathan Roelofs2014-09-051-0/+6
| | | | | | | | | | If you're crazy enough to want this sort of thing, then add -D_LIBCPP_HAS_NO_THREADS to your CXXFLAGS and --param=additiona_features=libcpp-has-no-threads to your lit commnad line. http://reviews.llvm.org/D3969 llvm-svn: 217271
* Implement LWG issue #2135. If something goes wrong in ↵Marshall Clow2014-03-261-2/+2
| | | | | | condition_variable::wait, call terminate() rather than throwing an error. Do this indirectly, by marking the call as 'noexcept'. This is better than just calling terminate() directly, because it gives a better error message on the console. llvm-svn: 204778
* Make cv_status a class enum. Fixes PR18314. Thanks to Andersca for the ↵Marshall Clow2013-12-231-11/+5
| | | | | | report and the patch. llvm-svn: 197921
* N3659: Shared locking in C++ Revision 2, c++1y onlyHoward Hinnant2013-09-211-31/+0
| | | | llvm-svn: 191127
* Nico Rieck: this patch series fixes visibility issues on Windows as ↵Howard Hinnant2013-08-121-2/+2
| | | | | | explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>. llvm-svn: 188192
* No functionality change at this time. I've split _LIBCPP_VISIBLE up into ↵Howard Hinnant2013-03-061-8/+8
| | | | | | two flags: _LIBCPP_TYPE_VIS and _LIBCPP_FUNC_VIS. This is in preparation for taking advantage of clang's new __type_visibility__ attribute. llvm-svn: 176593
* Rename uses of _ and __ because these are getting stepped on by macros from ↵Howard Hinnant2012-10-301-3/+3
| | | | | | other system code. llvm-svn: 167038
* Dimitry Andric: FreeBSD porting tweaks for PTHREAD_MUTEX_INITIALIZER and ↵Howard Hinnant2012-09-111-2/+2
| | | | | | PTHREAD_COND_INITIALIZER llvm-svn: 163626
* Change sleep_for, sleep_until, and the condition_variable timed waitHoward Hinnant2012-08-301-22/+10
| | | | | | | | | | | | | functions to protect against duration and time_point overflow. Since we're about to wait anyway, we can afford to spend a few more cycles on this checking. I purposefully did not treat the timed try_locks with overflow checking. This fixes http://llvm.org/bugs/show_bug.cgi?id=13721 . I'm unsure if the standard needs clarification in this area, or if this is simply QOI. The <chrono> facilities were never intended to overflow check, but just to not overflow if durations stayed within +/- 292 years. llvm-svn: 162925
* noexcept applied to <condition_variable>.Howard Hinnant2012-07-211-2/+2
| | | | llvm-svn: 160605
* noexcept and constexpr applied to <mutex>.Howard Hinnant2012-07-211-23/+26
| | | | llvm-svn: 160604
* Apply constexpr to the mutex constructor. As a conforming extension, apply ↵Howard Hinnant2012-07-071-0/+8
| | | | | | constexpr to the condition_variable constructor. These are important because it enables the compiler to construct these types at compile time, even though the object will be non-const. Since they are constructed at compile time, there is no chance of a data race before they are constructed. llvm-svn: 159901
* Modernize conversion to bool to the explicit bool conversion operator ↵Howard Hinnant2012-02-211-1/+1
| | | | | | (library wide). This fixes http://llvm.org/bugs/show_bug.cgi?id=12058. llvm-svn: 151088
* Windows support by Ruben Van Boxem.Howard Hinnant2011-10-171-0/+2
| | | | llvm-svn: 142235
* _STD -> _VSTD to avoid macro clash on windowsHoward Hinnant2011-06-301-3/+3
| | | | llvm-svn: 134190
OpenPOWER on IntegriCloud