summaryrefslogtreecommitdiffstats
path: root/libcxx/include/memory
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Rework compressed pair constructors.Eric Fiselier2019-12-161-66/+29
| | | | | | | | | | | | This patch de-duplicates most compressed pair constructors to use the same code in C++11 and C++03. Part of doing that is deleting the "__second_tag()" and replacing it with a "__value_init_tag()" which has the same effect, but allows for the removal of the special "one-arg" first element constructor. This patch is intended to have no semantic change.
* Add default initialization to compressed_pair.Eric Fiselier2019-12-161-0/+7
| | | | | | | | | | This change introduces the __default_init_tag to memory, and a corresponding element constructor to allow for default initialization of either of the pair values. This is useful for classes such as std::string where most (all) constructors explicitly initialize the values in the constructor. Patch by Martijn Vels (mvels@google.com) Reviewed as https://reviews.llvm.org/D70617
* [libc++] Rename __to_raw_pointer to __to_address.Eric Fiselier2019-11-161-27/+38
| | | | | | | This function has the same behavior as the now-standand std::to_address. Re-using the name makes the behavior more clear, and in the future it will allow us to correctly get the raw pointer for user provided pointer types.
* [libcxx] Remove shared_ptr::make_sharedZoe Carver2019-10-221-24/+21
| | | | | | | | | | | | | | Summary: This patch removes `shared_ptr::make_shared` as it is not part of the standard. This patch also adds __create_with_cntrl_block, which is a help function that can be used in std::allocate_shared and std::make_shared. This is the third patch (out of 4) from D66178. Reviewers: EricWF, mclow.lists, ldionne Subscribers: christof, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D68805 llvm-svn: 375504
* [libc++] Remove C++03 variadics in shared_ptr (v2)Zoe Carver2019-10-071-70/+0
| | | | | | | | | | | | | | Summary: In my last patch (D67675) I forgot a few variadics. This patch removes the remaining make_shared and allocate_shared C++03 variadics. Reviewers: ldionne, EricWF, mclow.lists Subscribers: christof, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D68000 llvm-svn: 373971
* [libcxx] Do not implicitly #include assert.hDavid Zarzycki2019-09-261-1/+0
| | | | | | | | | Users should only get the assert() macros if they explicitly include them. Found after switching from the GNU C++ stdlib to the LLVM C++ stdlib. llvm-svn: 372963
* [libc++] Remove C++03 variadics in shared_ptrZoe Carver2019-09-241-194/+0
| | | | | | | | | | | | | | Summary: As suggested by @ldionne in D66178, this patch removes C++03 variadics //only//. Following patches will apply more updates. Reviewers: ldionne, EricWF, mclow.lists Subscribers: christof, dexonsmith, libcxx-commits, ldionne Tags: #libc Differential Revision: https://reviews.llvm.org/D67675 llvm-svn: 372780
* Recommit r370502: Make `vector` unconditionally move elements whenEric Fiselier2019-09-131-7/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | exceptions are disabled. The patch was reverted due to some confusion about non-movable types. ie types that explicitly delete their move constructors. However, such types do not meet the requirement for `MoveConstructible`, which is required by `std::vector`: Summary: `std::vector<T>` is free choose between using copy or move operations when it needs to resize. The standard only candidates that the correct exception safety guarantees are provided. When exceptions are disabled these guarantees are trivially satisfied. Meaning vector is free to optimize it's implementation by moving instead of copying. This patch makes `std::vector` unconditionally move elements when exceptions are disabled. This optimization is conforming according to the current standard wording. There are concerns that moving in `-fno-noexceptions`mode will be a surprise to users. For example, a user may be surprised to find their code is slower with exceptions enabled than it is disabled. I'm sympathetic to this surprised, but I don't think it should block this optimization. Reviewers: mclow.lists, ldionne, rsmith Reviewed By: ldionne Subscribers: zoecarver, christof, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D62228 llvm-svn: 371867
* [libc++] Revert "Make `vector` unconditionally move elements when exceptions ↵Louis Dionne2019-09-051-19/+7
| | | | | | | | | | are disabled." This reverts r370502, which broke the use case of a copy-only T (with a deleted move constructor) when exceptions are disabled. Until we figure out the right behavior, I'm reverting the commit. llvm-svn: 371068
* Make `vector` unconditionally move elements when exceptions are disabled.Eric Fiselier2019-08-301-7/+19
| | | | | | | | | | | | | | | | | | | | | | | | Summary: `std::vector<T>` is free choose between using copy or move operations when it needs to resize. The standard only candidates that the correct exception safety guarantees are provided. When exceptions are disabled these guarantees are trivially satisfied. Meaning vector is free to optimize it's implementation by moving instead of copying. This patch makes `std::vector` unconditionally move elements when exceptions are disabled. This optimization is conforming according to the current standard wording. There are concerns that moving in `-fno-noexceptions`mode will be a surprise to users. For example, a user may be surprised to find their code is slower with exceptions enabled than it is disabled. I'm sympathetic to this surprised, but I don't think it should block this optimization. Reviewers: mclow.lists, ldionne, rsmith Reviewed By: ldionne Subscribers: zoecarver, christof, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D62228 llvm-svn: 370502
* [libc++] reverts commit a5f5aad568bb7a91ceee47641f3076ac339ef8c7.Zoe Carver2019-08-191-110/+260
| | | | | | | | | The commit being reverted caused segfaults when building with libc++ and GCC (and possibly other configurations). Differential Revision: https://reviews.llvm.org/D62868 llvm-svn: 369270
* This commit removes std::shared_ptr::make_shared and ↵Zoe Carver2019-08-141-260/+110
| | | | | | std::shared_ptr::allocate_shared as they are not part of the standard. This commit also adds the helper function "__create_with_cntrl_block" which std::allocate_shared and std::make_shared have been updated to use. llvm-svn: 368885
* [pstl][libc++] Provide uglified header names for interface headersLouis Dionne2019-08-061-1/+1
| | | | | | | | | | | For the few (currently four) headers that make up the PSTL's interface to other Standard Libraries, provide a stable uglified header file that can be included by those Standard Libraries. We can then more easily change the internal organization of the PSTL without having to change the integration with Standard Libraries. llvm-svn: 368088
* [libc++] Take 2: Integrate the PSTL into libc++Louis Dionne2019-08-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when configuring libc++ in CMake. When that option is enabled, libc++ will assume that the PSTL can be found somewhere on the CMake module path, and it will provide the C++17 parallel algorithms based on the PSTL (that is assumed to be available). The commit also adds support for running the PSTL tests as part of the libc++ test suite. The first attempt to commit this failed because it exposed a bug in the tests for modules. Now that this has been fixed, it should be safe to commit this. Reviewers: EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF Tags: #libc Differential Revision: https://reviews.llvm.org/D60480 llvm-svn: 367903
* Revert "[libc++] Integrate the PSTL into libc++"Louis Dionne2019-07-191-4/+0
| | | | | | | This reverts r366593, which caused unforeseen breakage on the build bots. I'm reverting until the problems have been figured out and fixed. llvm-svn: 366603
* [libc++] Integrate the PSTL into libc++Louis Dionne2019-07-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when configuring libc++ in CMake. When that option is enabled, libc++ will assume that the PSTL can be found somewhere on the CMake module path, and it will provide the C++17 parallel algorithms based on the PSTL (that is assumed to be available). The commit also adds support for running the PSTL tests as part of the libc++ test suite. Reviewers: rodgert, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF Tags: #libc Differential Revision: https://reviews.llvm.org/D60480 llvm-svn: 366593
* Use C++11 implementation of unique_ptr in C++03.Eric Fiselier2019-06-231-157/+51
| | | | llvm-svn: 364161
* Make move and forward work in C++03.Eric Fiselier2019-06-211-32/+10
| | | | | | | | | | | | | | | | | | | | | These functions are key to allowing the use of rvalues and variadics in C++03 mode. Everything works the same as in C++11, except for one tangentially related case: struct T { T(T &&) = default; }; In C++11, T has a deleted copy constructor. But in C++03 Clang gives it both a move and a copy constructor. This seems reasonable enough given the extensions it's using. The other changes in this patch were the minimal set required to keep the tests passing after the move/forward change. Most notably the removal of the `__rv<unique_ptr>` hack that was present in an attempt to make unique_ptr move only without language support. llvm-svn: 364063
* Apply [[nodebug]] to typedefs throughout the STL.Eric Fiselier2019-06-121-57/+57
| | | | | | | | | | | | | | | | When applied to a typedef or alias template, the [[nodebug]] attribute makes the typedef transparent to the debugger, so instead of seeing `std::__function::__alloc_func<remove_reference<void(&)()>::type, allocator<remove_reference<void(&)()>, void()>::_Target` you see `void(&)()` as the type of the variable in your debugger. Removing all this SFINAE noise from debug info has huge binary size wins, in addition to improving the readability. For now this change is on by default. Users can override it by specifying -D_LIBCPP_NODEBUG_TYPE= llvm-svn: 363117
* Substantially reduce instantiations and debug size of std::functionEric Fiselier2019-06-081-0/+46
| | | | | | | | | | | | | | | | | std::function uses a standard allocator to manage its memory, however standard allocators are templates and using them correctly requires a stupid amount of instantiations. This leads to a substantial increase in debug info and object sizes. This patch addresses the issue by dropping the allocator when possible and using raw new and delete to get memory. This change decreases the object file size for the test func.wrap.func.con/F.pass.cpp by 33% and the final binary by 29% (when compiled with -g -ggnu-pubnames -gpubnames). It also roughly halfs the number of entries in the pubnames and pubtype sections. llvm-svn: 362865
* Remove libc++ checks and workarounds for unsupported old versions of GCC (<4.9).Richard Smith2019-04-251-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D61107 llvm-svn: 359232
* 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
* Move internal usages of `alignof`/`__alignof` to use `_LIBCPP_ALIGNOF`. Eric Fiselier2019-01-161-8/+8
| | | | | | | | | | | | | | | | | | | | | Summary: Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See llvm.org/PR39713 This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used. This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement. I think we should commit this change immediately, and decide what we want to do about the ABI afterwards. Reviewers: ldionne, EricWF Reviewed By: ldionne, EricWF Subscribers: jyknight, christof, libcxx-commits Differential Revision: https://reviews.llvm.org/D54814 llvm-svn: 351289
* [libcxx] Optimize vectors construction of trivial types from an iterator ↵Volodymyr Sapsai2019-01-081-9/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | range with const-ness mismatch. We already have a specialization that will use memcpy for construction of trivial types from an iterator range like std::vector<int>(int *, int *); But if we have const-ness mismatch like std::vector<int>(const int *, const int *); we would use a slow path that copies each element individually. This change enables the optimal specialization for const-ness mismatch. Fixes PR37574. Contributions to the patch are made by Arthur O'Dwyer, Louis Dionne. rdar://problem/40485845 Reviewers: mclow.lists, EricWF, ldionne, scanon Reviewed By: ldionne Subscribers: christof, ldionne, howard.hinnant, cfe-commits Differential Revision: https://reviews.llvm.org/D48342 llvm-svn: 350583
* [libcxx] Use custom allocator's `construct` in C++03 when available.Volodymyr Sapsai2018-12-191-21/+27
| | | | | | | | | | | | | | | | | Makes libc++ behavior consistent between C++03 and C++11. Can use `decltype` in C++03 because `include/__config` defines a macro when `decltype` is not available. Reviewers: mclow.lists, EricWF, erik.pilkington, ldionne Reviewed By: ldionne Subscribers: dexonsmith, cfe-commits, howard.hinnant, ldionne, christof, jkorous, Quuxplusone Differential Revision: https://reviews.llvm.org/D48753 llvm-svn: 349676
* [libcxx] Add paranoid cast-to-void in comma operatorLouis Dionne2018-12-071-1/+1
| | | | llvm-svn: 348611
* Revert "Move internal usages of `alignof`/`__alignof` to use ↵Eric Fiselier2018-11-281-7/+7
| | | | | | | | | | | `_LIBCPP_ALIGNOF`. " This reverts commit 087f065cb0c7463f521a62599884493aaee2ea12. The tests were failing on 32 bit builds, and I don't have time to clean them up right now. I'll recommit tomorrow with fixed tests. llvm-svn: 347816
* Move internal usages of `alignof`/`__alignof` to use `_LIBCPP_ALIGNOF`. Eric Fiselier2018-11-281-7/+7
| | | | | | | | | | | | | | | | | | | | | Summary: Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See llvm.org/PR39713 This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used. This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement. I think we should commit this change immediately, and decide what we want to do about the ABI afterwards. Reviewers: ldionne, EricWF Reviewed By: EricWF Subscribers: christof, libcxx-commits Differential Revision: https://reviews.llvm.org/D54814 llvm-svn: 347787
* [libcxx] Implement http://wg21.link/p1006, constexpr in pointer_traitsLouis Dionne2018-11-131-2/+2
| | | | | | | | | | | | | | | | Summary: P1006 adds support for constexpr in the specialization of pointer_traits for raw pointers. This is necessary in order to use pointer_traits in the upcoming constexpr containers. We expect P1006 to be voted into the working draft for C++20 at the San Diego meeting. Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D53867 llvm-svn: 346764
* Fix incorrect use of aligned allocation in get_temporary_buffer.Eric Fiselier2018-10-261-1/+1
| | | | llvm-svn: 345403
* Implement sized deallocation for std::allocator and friends.Eric Fiselier2018-10-251-5/+5
| | | | | | | | | | | | | | | | | | | Summary: C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own). This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown. On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem. Reviewers: ldionne, mclow.lists Reviewed By: ldionne Subscribers: rsmith, ckennelly, libcxx-commits, christof Differential Revision: https://reviews.llvm.org/D53120 llvm-svn: 345281
* Temporarily Revert "Implement sized deallocation for std::allocator and ↵Eric Christopher2018-10-251-5/+5
| | | | | | | | | | friends." This is breaking the bots here (and related): http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-asan/builds/1428 This reverts commit r345214. llvm-svn: 345239
* Implement sized deallocation for std::allocator and friends.Eric Fiselier2018-10-241-5/+5
| | | | | | | | | | | | | | | | | | | Summary: C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own). This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown. On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem. Reviewers: ldionne, mclow.lists Reviewed By: ldionne Subscribers: rsmith, ckennelly, libcxx-commits, christof Differential Revision: https://reviews.llvm.org/D53120 llvm-svn: 345214
* Distinguish between library and language support for aligned allocation.Eric Fiselier2018-10-111-1/+1
| | | | | | | | | | | | | | | | | | | | There are two cases: 1. The library has all it needs to provide align_val_t and the new/delete overloads needed to support aligned allocation. 2. The compiler has actually turned the language feature on. There are times where libc++ needs to distinguish between the two. This patch adds the additional macro _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION which denotes when case (1) does not hold. _LIBCPP_HAS_NO_ALIGNED_ALLOCATION is defined whenever _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION is defined, or when the compiler has not enabled the language feature. Additionally this patch cleans up a number of other macros related to detection of aligned allocation machinery. llvm-svn: 344207
* Fix even more Clang warnings.Eric Fiselier2018-10-011-2/+5
| | | | | | | This patch disables shift-sign-overflow warnings for now. It also fixes most -Wfloat-equal warnings and -Wextra-semi warnings. llvm-svn: 343438
* [libc++] Add deprecated attributes to many deprecated componentsLouis Dionne2018-09-231-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: These deprecation warnings are opt-in: they are only enabled when the _LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case by default. Note that this is a first step in the right direction, but I wasn't able to get an exhaustive list of all deprecated components per standard, so there's certainly stuff that's missing. The list of components this commit marks as deprecated is: in C++11: - auto_ptr, auto_ptr_ref - binder1st, binder2nd, bind1st(), bind2nd() - pointer_to_unary_function, pointer_to_binary_function, ptr_fun() - mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun() - mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref() in C++14: - random_shuffle() in C++17: - unary_negate, binary_negate, not1(), not2() <rdar://problem/18168350> Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D48912 llvm-svn: 342843
* [libc++] Add _LIBCPP_ENABLE_NODISCARD and _LIBCPP_NODISCARD_EXT to allow ↵Roman Lebedev2018-09-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pre-C++2a [[nodiscard]] Summary: The `[[nodiscard]]` attribute is intended to help users find bugs where function return values are ignored when they shouldn't be. After C++17 the C++ standard has started to declared such library functions as `[[nodiscard]]`. However, this application is limited and applies only to dialects after C++17. Users who want help diagnosing misuses of STL functions may desire a more liberal application of `[[nodiscard]]`. For this reason libc++ provides an extension that does just that! The extension must be enabled by defining `_LIBCPP_ENABLE_NODISCARD`. The extended applications of `[[nodiscard]]` takes two forms: 1. Backporting `[[nodiscard]]` to entities declared as such by the standard in newer dialects, but not in the present one. 2. Extended applications of `[[nodiscard]]`, at the libraries discretion, applied to entities never declared as such by the standard. Users may also opt-out of additional applications `[[nodiscard]]` using additional macros. Applications of the first form, which backport `[[nodiscard]]` from a newer dialect may be disabled using macros specific to the dialect it was added. For example `_LIBCPP_DISABLE_NODISCARD_AFTER_CXX17`. Applications of the second form, which are pure extensions, may be disabled by defining `_LIBCPP_DISABLE_NODISCARD_EXT`. This patch was originally written by me (Roman Lebedev), then but then reworked by Eric Fiselier. Reviewers: mclow.lists, thakis, EricWF Reviewed By: thakis, EricWF Subscribers: llvm-commits, mclow.lists, lebedev.ri, EricWF, rjmccall, Quuxplusone, cfe-commits, christof Differential Revision: https://reviews.llvm.org/D45179 llvm-svn: 342808
* Implement the infrastructure for feature-test macros. Very few actual ↵Marshall Clow2018-09-121-0/+1
| | | | | | feature test macros, though. Reviewed as: https://reviews.llvm.org/D51955 llvm-svn: 342073
* Use addressof instead of operator& in make_shared. Fixes PR38729. As a ↵Marshall Clow2018-08-281-3/+3
| | | | | | drive-by, make the same change in raw_storage_iterator (twice). llvm-svn: 340823
* libcxx: Mark __temp_value::__temp_value as _LIBCPP_NO_CFI.Peter Collingbourne2018-08-151-2/+5
| | | | | | | | | | | | | | This constructor needs to cast a pointer to uninitialized memory to a pointer to object type in order to call allocator_traits::construct(). This cast is not allowed when CFI cast checks are enabled. I did this instead of marking __addr() as _LIBCPP_NO_CFI so that we don't lose CFI checks on get() or the dtor. Differential Revision: https://reviews.llvm.org/D50743 llvm-svn: 339797
* [libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since ↵Louis Dionne2018-08-011-3/+3
| | | | | | | | | | | | | | _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
* [libc++] Take 2: Replace uses of _LIBCPP_ALWAYS_INLINE by ↵Louis Dionne2018-07-111-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | _LIBCPP_INLINE_VISIBILITY Summary: We never actually mean to always inline a function -- all the uses of the macro I could find are actually attempts to control the visibility of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which is actually always defined the same. This change is orthogonal to the decision of what we're actually going to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by having one canonical way of doing things. Note that this commit had originally been applied in r336369 and then reverted in r336382 because of unforeseen problems. Both of these problems have now been fixed. Reviewers: EricWF, mclow.lists Subscribers: christof, dexonsmith, erikvanderpoel Differential Revision: https://reviews.llvm.org/D48892 llvm-svn: 336866
* Revert "[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by ↵Louis Dionne2018-07-051-3/+3
| | | | | | | | | | | | | | | _LIBCPP_INLINE_VISIBILITY" This reverts commit r336369. The commit had two problems: 1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of _LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the dylib and the check-cxx-abilist failing. 2. The LLDB tests started failing because they undefine `_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and fix the tests before we can go forward with this change. llvm-svn: 336382
* [libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITYLouis Dionne2018-07-051-3/+3
| | | | | | | | | | | | | | | | | | | | Summary: We never actually mean to always inline a function -- all the uses of the macro I could find are actually attempts to control the visibility of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which is actually always defined the same. This change is orthogonal to the decision of what we're actually going to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by having one canonical way of doing things. Reviewers: EricWF Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists Differential Revision: https://reviews.llvm.org/D48892 llvm-svn: 336369
* Implement LWG 2946, 3075 and 3076. Reviewed as https://reviews.llvm.org/D48616Marshall Clow2018-07-021-4/+4
| | | | llvm-svn: 336132
* Fix PR22634 - std::allocator doesn't respect over-aligned types.Eric Fiselier2018-03-221-30/+7
| | | | | | | | | | | | | | | | | | | | This patch fixes std::allocator, and more specifically, all users of __libcpp_allocate and __libcpp_deallocate, to support over-aligned types. __libcpp_allocate/deallocate now take an alignment parameter, and when the specified alignment is greater than that supported by malloc/new, the aligned version of operator new is called (assuming it's available). When aligned new isn't available, the old behavior has been kept, and the alignment parameter is ignored. This patch depends on recent changes to __builtin_operator_new/delete which allow them to be used to call any regular new/delete operator. By using __builtin_operator_new/delete when possible, the new/delete erasure optimization is maintained. llvm-svn: 328180
* Implement LWG3035: std::allocator's constructors should be constexpr.Marshall Clow2018-03-201-7/+18
| | | | llvm-svn: 328059
* Implement LWG#2908 - The less-than operator for shared pointers could do ↵Marshall Clow2018-02-121-0/+5
| | | | | | more, and mark 2878 as complete as well (we already do that) llvm-svn: 324911
* Make std::get_temporary_buffer respect overaligned types when possibleRichard Smith2018-02-011-1/+48
| | | | | | | | Patch by Chris Kennelly! Differential Revision: https://reviews.llvm.org/D41746 llvm-svn: 324020
* libcxx: Disable CFI in function std::get_temporary_buffer.Peter Collingbourne2018-01-171-0/+1
| | | | | | | | | The specification of this function mandates a cast to uninitialized T*, which is forbidden under CFI. Differential Revision: https://reviews.llvm.org/D42146 llvm-svn: 322744
OpenPOWER on IntegriCloud