summaryrefslogtreecommitdiffstats
path: root/libcxx/include/new
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Take 2: Implement LWG 2510Louis Dionne2019-09-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | | | 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
* P0722R3: Implement library support for destroying deleteEric Fiselier2019-05-231-0/+15
| | | | | | | | | | | | | | | | | | Summary: This provides the `std::destroying_delete_t` declaration in C++2a and after. (Even when the compiler doesn't support the language feature). However, the feature test macro `__cpp_lib_destroying_delete` is only defined when we have both language support and C++2a. Reviewers: ldionne, ckennelly, serge-sans-paille, EricWF Reviewed By: EricWF Subscribers: dexonsmith, riccibruno, christof, jwakely, jdoerfert, mclow.lists, ldionne, libcxx-commits Differential Revision: https://reviews.llvm.org/D55840 llvm-svn: 361572
* Make VCRuntime ABI configuration a first-class option.Eric Fiselier2019-03-051-6/+6
| | | | | | | | | | | | | | | | | | | | | | | Summary: On Windows we currently provide two separate ABI configurations. One which defers to `vcruntime` to provide the C++ runtime and another which doesn't. Using `vcruntime` allows interoperability which programs compiled against the MSVC STL, and should be preferred whenever possible. When deferring to `vcruntime` much of the ABI we provide changes. Including the layout of `<stdexcept>` types, their vtables, and how the linkage of their members. This patch introduces the `_LIBCPP_ABI_VCRUNTIME` macro to denote this configuration. It also cleans up the existing configuration for using `vcruntime`. This cleanup lays the groundwork for fixing a number of ABI and interoperability bugs in `<stdexcept>`. Reviewers: thomasanderson, ldionne, smeenai Reviewed By: smeenai Subscribers: jdoerfert, libcxx-commits, #libc Differential Revision: https://reviews.llvm.org/D58942 llvm-svn: 355366
* [libc++] Rename _NOALIAS macro to _LIBCPP_NOALIASLouis Dionne2019-02-261-4/+4
| | | | | | | | | | | | | | Summary: For consistency, libc++ macros always start with _LIBCPP. This should have no functionality change. Reviewers: EricWF, mclow.lists Subscribers: christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D58558 llvm-svn: 354848
* 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
* [libcxx] Remove bad_array_lengthLouis Dionne2018-11-291-35/+0
| | | | | | | | | | | | | | | | Summary: std::bad_array_length was added by n3467, but this never made it into C++. This commit removes the definition of std::bad_array_length from the headers AND from the shared library. See the comments in the ABI changelog for details about the ABI implications of this change. Reviewers: mclow.lists, dexonsmith, howard.hinnant, EricWF Subscribers: christof, jkorous, libcxx-commits Differential Revision: https://reviews.llvm.org/D54804 llvm-svn: 347903
* Implement sized deallocation for std::allocator and friends.Eric Fiselier2018-10-251-13/+88
| | | | | | | | | | | | | | | | | | | 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-88/+13
| | | | | | | | | | 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-13/+88
| | | | | | | | | | | | | | | | | | | 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
* Fix use of removed _LIBCPP_HAS_NO_BUILTIN_ALIGNED_OPERATOR_NEW_DELETEEric Fiselier2018-10-111-1/+1
| | | | | | | It was replaced with the better named _LIBCPP_HAS_NO_BUILTIN_OVERLOADED_OPERATOR_NEW_DELETE. llvm-svn: 344214
* Distinguish between library and language support for aligned allocation.Eric Fiselier2018-10-111-21/+18
| | | | | | | | | | | | | | | | | | | | 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
* Attempt to fix aligned allocation configuration under clang-clEric Fiselier2018-10-011-0/+4
| | | | | | | | | | When we're using clang-cl and Microsoft's runtime implementation, we don't provide align_val_t or aligned new/delete ourselves. This patch updates the _LIBCPP_HAS_NO_ALIGNED_ALLOCATION macro to reflect this. llvm-svn: 343441
* 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
* [libc++] Enable aligned allocation based on feature test macro, irrespective ↵Louis Dionne2018-08-101-7/+0
| | | | | | | | | | | | | | | | | | | | | of standard Summary: The current code enables aligned allocation functions when compiling in C++17 and later. This is a problem because aligned allocation functions might not be supported on the target platform, which leads to an error at link time. Since r338934, Clang knows not to define __cpp_aligned_new when it's not available on the target platform -- this commit takes advantage of that to only use aligned allocation functions when they are available. Reviewers: vsapsai, EricWF Subscribers: christof, dexonsmith, cfe-commits, EricWF, mclow.lists Differential Revision: https://reviews.llvm.org/D50344 llvm-svn: 339431
* [NFC][libc++] Consistently use spaces to indentLouis Dionne2018-08-031-2/+2
| | | | | | rdar://problem/19988944 llvm-svn: 338933
* [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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | _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-1/+1
| | | | | | | | | | | | | | | _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-1/+1
| | | | | | | | | | | | | | | | | | | | 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
* Fix PR22634 - std::allocator doesn't respect over-aligned types.Eric Fiselier2018-03-221-4/+45
| | | | | | | | | | | | | | | | | | | | 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
* Fix libcxx MSVC C++17 redefinition of 'align_val_t'Eric Fiselier2018-02-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch from charlieio@outlook.com Reviewed as https://reviews.llvm.org/D42354 When the following command is used: > clang-cl -std:c++17 -Iinclude\c++\v1 hello.cc c++.lib An error occurred: In file included from hello.cc:1: In file included from include\c++\v1\iostream:38: In file included from include\c++\v1\ios:216: In file included from include\c++\v1\__locale:15: In file included from include\c++\v1\string:477: In file included from include\c++\v1\string_view:176: In file included from include\c++\v1\__string:56: In file included from include\c++\v1\algorithm:643: In file included from include\c++\v1\memory:656: include\c++\v1\new(165,29): error: redefinition of 'align_val_t' enum class _LIBCPP_ENUM_VIS align_val_t : size_t { }; ^ C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\include\vcruntime_new.h(43,16): note: previous definition is here enum class align_val_t : size_t {}; ^ 1 error generated. vcruntime_new.h has defined align_val_t, libcxx need hide align_val_t. This patch fixes that error. llvm-svn: 324853
* Implement more of P0600: '[[nodiscard]] in the library' for C++2aMarshall Clow2017-12-041-20/+20
| | | | llvm-svn: 319710
* Add [[nodiscard]] to std::async as part of P0600.Marshall Clow2017-11-231-1/+1
| | | | llvm-svn: 318889
* Implement p0137r1 - std::launder. Reviewed as https://reviews.llvm.org/D40144Marshall Clow2017-11-221-0/+25
| | | | llvm-svn: 318864
* [libc++] Support Microsoft ABI without vcruntime headersShoaib Meenai2017-10-091-5/+5
| | | | | | | | | | | | | | | | | The vcruntime headers are hairy and clash with both libc++ headers themselves and other libraries. libc++ normally deals with the clashes by deferring to the vcruntime headers and silencing its own definitions, but for clients which don't want to depend on vcruntime headers, it's desirable to support the opposite, i.e. have libc++ provide its own definitions. Certain operator new/delete replacement scenarios are not currently supported in this mode, which requires some tests to be marked XFAIL. The added documentation has more details. Differential Revision: https://reviews.llvm.org/D38522 llvm-svn: 315234
* Revert "[libcxx] Annotate c++17 aligned new/delete operators with availability"Akira Hatanaka2017-06-301-10/+10
| | | | | | | | | | | | | This reverts commit r306310. r306310 causes clang to reject a call to an aligned allocation or deallocation function if it is not implemented in the standard library of the deployment target. This is not the desired behavior when users have defined their own aligned functions. rdar://problem/32664169 llvm-svn: 306859
* [libcxx] Annotate c++17 aligned new/delete operators with availabilityAkira Hatanaka2017-06-261-10/+10
| | | | | | | | | | | | | | | | | | | | | | | attribute. This is needed because older versions of libc++ do not have these operators. If users target an older deployment target and try to compile programs in which these operators are explicitly called, the compiler will complain. The following is the list of minimum deployment targets for the four OSes: macosx: 10.13 ios: 11.0 tvos: 11.0 watchos: 4.0 rdar://problem/32664169 Differential Revision: https://reviews.llvm.org/D34556 llvm-svn: 306310
* Add markup for libc++ dylib availabilityMehdi Amini2017-05-041-7/+9
| | | | | | | | | | | | | | | 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
* Recommit "Split exception.cpp and new.cpp implementation into different ↵Eric Fiselier2017-02-101-7/+19
| | | | | | | | | | | | | | | | | | | | | | files for different runtimes." This recommits r294707 with additional fixes. The main difference is libc++ now correctly builds without any ABI library. exception.cpp is a bloody mess. It's full of confusing #ifdef branches for each different ABI library we support, and it's getting unmaintainable. This patch breaks down exception.cpp into multiple different header files, roughly one per implementation. Additionally it moves the definitions of exceptions in new.cpp into the correct implementation header. This patch also removes an unmaintained libc++abi configuration. This configuration may still be used by Apple internally but there are no other possible users. If it turns out that Apple still uses this configuration internally I will re-add it in a later commit. See http://llvm.org/PR31904. llvm-svn: 294730
* Revert "Split exception.cpp and new.cpp implementation into different files ↵Eric Fiselier2017-02-101-18/+6
| | | | | | | | for different runtimes." The compiler-rt CMake configuration needs some tweaking before this can land. llvm-svn: 294727
* Split exception.cpp and new.cpp implementation into different files for ↵Eric Fiselier2017-02-101-6/+18
| | | | | | | | | | | | | | | | | | | different runtimes. exception.cpp is a bloody mess. It's full of confusing #ifdef branches for each different ABI library we support, and it's getting unmaintainable. This patch breaks down exception.cpp into multiple different header files, roughly one per implementation. Additionally it moves the definitions of exceptions in new.cpp into the correct implementation header. This patch also removes an unmaintained libc++abi configuration. This configuration may still be used by Apple internally but there are no other possible users. If it turns out that Apple still uses this configuration internally I will re-add it in a later commit. See http://llvm.org/PR31904. llvm-svn: 294707
* Revert accidentally changes which reverted r292582Eric Fiselier2017-01-211-1/+1
| | | | llvm-svn: 292717
* Implement P0513R0 - "Poisoning the Hash"Eric Fiselier2017-01-211-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Exactly what the title says. This patch also adds a `std::hash<nullptr_t>` specialization in C++17, but it was not added by this paper and I can't find the actual paper that adds it. See http://wg21.link/P0513R0 for more info. If there are no comments in the next couple of days I'll commit this Reviewers: mclow.lists, K-ballo, EricWF Reviewed By: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D28938 llvm-svn: 292684
* Still expose std::align_val_t in C++17 even if we don't have aligned new/delete.Eric Fiselier2017-01-201-1/+1
| | | | | | | | | | | r292564 disabled the aligned new/delete overloads on platforms without posix_memalign. Unfortunately that patch also disabled the align_val_t definition in C++17 as well. This patch causes align_val_t to be exposed in C++17 regardless of if we have the new/delete overloads. llvm-svn: 292582
* Disable aligned new/delete on Apple platforms without posix_memalignEric Fiselier2017-01-201-2/+3
| | | | | | | | | | | | | | | | | | | Summary: This patch disables the aligned new/delet overloads on Apple platforms without `posix_memalign`. This fixes libc++.dylib build regressions on such platforms. This fixes http://llvm.org/PR31448. This patch should also be merged into the 4.0 release branch Reviewers: mclow.lists, rsmith, dexonsmith, jeremyhu Reviewed By: mclow.lists Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D28931 llvm-svn: 292564
* [libc++] Tolerate presence of __deallocate macroEric Fiselier2017-01-071-3/+1
| | | | | | | | | | | | | | | Summary: On Windows the identifier `__deallocate` is defined as a macro by one of the Windows system headers. Previously libc++ worked around this by `#undef __deallocate` and generating a warning. However this causes the WIN32 version of `__threading_support` to always generate a warning on Windows. This is not OK. This patch renames all usages of `__deallocate` internally as to not conflict with the macro. Reviewers: mclow.lists, majnemer, rnk, rsmith, smeenai, compnerd Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D28426 llvm-svn: 291332
* Fix use of throw(...) spec with GCC in C++17Eric Fiselier2017-01-021-1/+1
| | | | llvm-svn: 290845
* [libc++] Fix preprocessor guard for overload declarationShoaib Meenai2016-11-181-1/+1
| | | | | | | | | Fix a typo in the conditional. Caught by going through list of removed symbols when building with hidden visibility. Differential Revision: https://reviews.llvm.org/D26825 llvm-svn: 287309
* [libc++] Introduce `_LIBCPP_OVERRIDABLE_FUNC_VIS`Shoaib Meenai2016-11-161-26/+20
| | | | | | | | | | This is a generalization of `_LIBCPP_NEW_DELETE_VIS`; the new macro name captures the semantics better, and also allows us to get rid of the `_WIN32` check in `include/new`. No functional change. Differential Revision: https://reviews.llvm.org/D26702 llvm-svn: 287164
* Implement P0035R4 -- Add C++17 aligned allocation functionsEric Fiselier2016-10-141-14/+65
| | | | | | | | | | | | | | | | Summary: This patch implements the library side of P0035R4. The implementation is thanks to @rsmith. In addition to the C++17 implementation, the library implementation can be explicitly turned on using `-faligned-allocation` in all dialects. Reviewers: mclow.lists, rsmith Subscribers: rsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D25591 llvm-svn: 284206
* [libc++] Correct explanation of _LIBCPP_NEW_DELETE_VISShoaib Meenai2016-10-121-1/+1
| | | | | | | | | | The behavior of this macro actually needs to apply universally on Windows and not just when using the Microsoft CRT. Update the macro definition and documentation accordingly. Differential Revision: https://reviews.llvm.org/D25145 llvm-svn: 284016
* [libc++] Clarify _LIBCPP_NEW_DELETE_VIS for WindowsShoaib Meenai2016-09-281-2/+2
| | | | | | | | | | | | | | | | | | Replace a stale reference to cxx_EXPORTS with _LIBCPP_BUILDING_LIBRARY, and clarify why the operator new and delete family of functions are marked dllexport when building but *not* dllimport when including the header externally. The new code is identical to the intent of the old code (and would be functionally equivalent were cxx_EXPORTS still defined when building libc++). The overall behavior is not ideal, since Microsoft's operator new and delete functions will get called instead of libc++'s, but I think consistently calling msvcrt's functions is better than either calling msvcrt's or libc++'s functions depending on header inclusion. Differential Revision: https://reviews.llvm.org/D25042 llvm-svn: 282644
* Try 2 - Remove <cstdlib> include from `<exception>`Eric Fiselier2016-09-061-0/+3
| | | | | | | | | | | This patch removes the `<cstdlib>` include from exception where it is no longer needed. Unlike my previous attempt this patch also adds <cstdlib> where needed in other headers like <new> and <typeinfo>. This won't fix the Firefox build issues discussed on IRC but it is more correct for libc++. llvm-svn: 280754
* Add an _LIBCPP_NORETURN inline function named __throw_XXX for each exception ↵Marshall Clow2016-08-251-2/+14
| | | | | | type we define. They either construct and throw the exception, or abort() (if exceptions are disabled). Use these functions everywhere instead of assert()ing when exceptions are disabled. WARNING: This is a behavior change - but only with exceptions disabled. Reviewed as: https://reviews.llvm.org/D23855. llvm-svn: 279744
* [libcxx] Rework sized delete.Eric Fiselier2015-05-191-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch does 2 main things: 1. Enable sized delete if the feature test macro `__cpp_sized_deallocation` is enabled. 2. Rework and cleanup all of the sized delete tests. Test Plan: The sized delete replacement tests are now split into 4 files: 1. sized_delete11.pass.cpp: Ensure overriding sized delete in C++11 has no effect. 2. sized_delete14.pass.cpp: Test overriding sized delete in C++14 and ensure it is called. This test fails on clang and GCC < 5.1. 3. size_delete_calls_unsized_delete_.pass.cpp: Test that the default sized delete calls unsized delete. 4. sized_delete_fsizeddeallocation.pass.cpp: Test overriding sized delete when -fsized-deallocation is passed. This test should pass on clang and GCC >= 5.1 I have also removed a lot of cruft from the old tests. They no longer replace the new handler and tests that it is called for bad allocations. Reviewers: mclow.lists Reviewed By: mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D9831 llvm-svn: 237662
* Fix for LWG Issue 2458: N3778 and new library deallocation signatures.Marshall Clow2015-05-181-6/+0
| | | | llvm-svn: 237592
* More on adding sized deallocation functions in libc++: Continuing from ↵Larisse Voufo2015-02-201-2/+6
| | | | | | r229281, this adds version guards and test cases. llvm-svn: 229968
* Implement C++14's sized deallocation functions, since there are no longer ↵Larisse Voufo2015-02-151-0/+10
| | | | | | implicitly defined by clang, as of r229241. llvm-svn: 229281
OpenPOWER on IntegriCloud