summaryrefslogtreecommitdiffstats
path: root/libcxx/include/valarray
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Cleanup and enable multiple warnings.Eric Fiselier2019-12-121-19/+7
| | | | | | | | | | Too many warnings are being disabled too quickly. Warnings are important to keeping libc++ correct. This patch re-enables two warnings: -Wconstant-evaluated and -Wdeprecated-copy. In future, all warnings disabled for the test suite should require an attached bug. The bug should state the plan for re-enabling that warning, or a strong case why it should remain disabled.
* Remove incorrect explicit instantiation declarations for valarrayRichard Smith2019-04-251-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | libc++ ABI v1 provides three valarray symbols as part of the shared library: valarray<size_t>::valarray(size_t) valarray<size_t>::~valarray() valarray<size_t>::resize(size_t, size_t) The first two of these are intended to be removed in V2 of the ABI: they're attributed _LIBCPP_HIDE_FROM_ABI_AFTER_V1, and it appears that the intention is that these symbols from the library are not used even when building using the V1 ABI. However, there are explicit instantiation declarations for all three symbols in the header, which are not correct as we do not intend to find an instantiation of these functions that is provided elsewhere. (A recent change to clang to properly diagnose explicit instantiation declarations of internal linkage functions -- required by [temp.explicit]p13 -- had to be rolled back because it diagnosed these explicit instantiations.) Remove the explicit instantiation declarations, and remove the explicit instantiation definitions for V2 of the libc++ ABI onwards. llvm-svn: 359243
* Fix a number of bugs in __val_expr's subset operator[].Eric Fiselier2019-04-021-4/+19
| | | | | | | | The current definitions were entirely broken. They didn't call any existing constructor and the forgot to friend the expression types they were trying to construct. llvm-svn: 357453
* 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-20/+20
| | | | | | | | | | | | | | | | | | | | | 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
* Revert "Move internal usages of `alignof`/`__alignof` to use ↵Eric Fiselier2018-11-281-20/+20
| | | | | | | | | | | `_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-20/+20
| | | | | | | | | | | | | | | | | | | | | 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
* fix incorrect placement of _LIBCPP_ALWAYS_INLINE in valarrayEric Fiselier2018-10-251-1/+2
| | | | llvm-svn: 345289
* Implement sized deallocation for std::allocator and friends.Eric Fiselier2018-10-251-33/+35
| | | | | | | | | | | | | | | | | | | 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-35/+33
| | | | | | | | | | 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-33/+35
| | | | | | | | | | | | | | | | | | | 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
* [libcxx] Remove _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITYLouis Dionne2018-10-161-2/+2
| | | | | | | | | | | | That macro has been defined to _LIBCPP_HIDE_FROM_ABI_AFTER_V1 for many weeks now, so we're actually replacing uses of it for uses of _LIBCPP_HIDE_FROM_ABI_AFTER_V1 directly. This should not change or break anything since the two macros are 100% equivalent, unless somebody is (incorrectly!) relying on _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY being defined. llvm-svn: 344641
* Fix PR22634 - std::allocator doesn't respect over-aligned types.Eric Fiselier2018-03-221-20/+38
| | | | | | | | | | | | | | | | | | | | 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
* [libcxx] Avoid spurious construction of valarray elementsMikhail Maltsev2018-02-081-21/+58
| | | | | | | | | | | | | | | | | | | | | Summary: Currently libc++ implements some operations on valarray by using the resize method. This method has a parameter with a default value. Because of this, valarray may spuriously construct and destruct objects of valarray's element type. This patch fixes this issue and adds corresponding test cases. Reviewers: EricWF, mclow.lists Reviewed By: mclow.lists Subscribers: rogfer01, cfe-commits Differential Revision: https://reviews.llvm.org/D41992 llvm-svn: 324596
* [Libc++] Use #pragma push_macro/pop_macro to better handle min/max on WindowsEric Fiselier2017-05-311-2/+6
| | | | | | | | | | | | | | | | 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
* Cleanup _LIBCPP_HAS_NO_<c++11-feature> macros in the numeric tests and headersEric Fiselier2017-04-191-40/+28
| | | | llvm-svn: 300632
* [libc++] Tolerate presence of __deallocate macroEric Fiselier2017-01-071-2/+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
* [NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VISEric Fiselier2017-01-041-18/+18
| | | | | | | | | | | | | 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
* Use _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY in valarray to support ↵Eric Fiselier2016-09-161-3/+3
| | | | | | | | | | | | | attribute((internal_linkage)). The externally instantiated member functions must be declared using _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY, not _LIBCPP_INLINE_VISIBILITY, in order to be properly exported when using __attribute__((internal_linkage)). Otherwise the explicit instantiations will obviously have internal linkage and will not be exported from the dylib. llvm-svn: 281684
* Mark declarations of externally instantiated functions as inline so GCC ↵Eric Fiselier2015-12-151-2/+2
| | | | | | doesn't complain. llvm-svn: 255599
* Cleanup: move visibility/linkage attributes to the first declaration.Evgeniy Stepanov2015-11-071-106/+204
| | | | | | | | | | | | 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
* Handle function name conflicts in _LIBCPP_MSVCRT modeSaleem Abdulrasool2015-02-131-0/+1
| | | | | | | | | | Visual Studio's SAL extension uses a macro named __deallocate. This macro is used pervasively, and gets included through various different ways. This conflicts with the similarly named interfaces in libc++. Introduce a undef header similar to __undef_min_max to handle this. This fixes a number of errors due to the macro replacing the function name. llvm-svn: 229162
* Add return statement to slice_array and mask_array assignment. Closes PR20614.Eric Fiselier2014-08-121-0/+2
| | | | | | | | | | This patch just adds the required return statements to slice_array::operator= and mask_array::operator=. Tests were added to check that the return value is the same as the object assigned to. llvm-svn: 215414
* Use __builtin_operator_new/__builtin_operator_delete when available. ThisRichard Smith2014-06-041-18/+19
| | | | | | allows allocations and deallocations to be optimized out. llvm-svn: 210211
* G M: Make valarray a little more forgiving to compilers not quite so ↵Howard Hinnant2013-09-131-1/+1
| | | | | | gifted. This has no impact on clang. llvm-svn: 190731
* Nico Rieck: this patch series fixes visibility issues on Windows as ↵Howard Hinnant2013-08-121-22/+22
| | | | | | 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-20/+20
| | | | | | 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
* Provide a way to disable use of extern templates in libc++. This is ↵Howard Hinnant2012-11-061-3/+3
| | | | | | intended for the clients of libc++, not the libc++ build. The dylib should always contain the extern templates. To disable the client needs to put -D'_LIBCPP_EXTERN_TEMPLATE(...)=' on the command line. llvm-svn: 167486
* Dimitry Andric: many visibility fixes. Howard: Much appreciated. Can you ↵Howard Hinnant2012-09-141-6/+10
| | | | | | send me a patch to CREDITS.TXT? llvm-svn: 163862
* noexcept applied to <valarray>.Howard Hinnant2012-07-211-11/+11
| | | | llvm-svn: 160592
* Revert my _LIBCPP_INLINE_VISIBILITY changes, r157097 and r157107Douglas Gregor2012-05-191-222/+129
| | | | llvm-svn: 157108
* valarray resize should not be _LIBCPP_INLINE_VISIBILITYDouglas Gregor2012-05-191-1/+0
| | | | llvm-svn: 157107
* Move _LIBCPP_VISIBLE_INLINE from the out-of-line definitions of memberDouglas Gregor2012-05-191-129/+223
| | | | | | | functions to the original declarations, so that Clang will actually see them. Part of <rdar://problem/11489333>. llvm-svn: 157097
* Quash a whole bunch of warningsHoward Hinnant2011-12-011-4/+4
| | | | llvm-svn: 145624
* Further macro protection by replacing _[A-Z] with _[A-Z]pHoward Hinnant2011-11-291-7/+7
| | | | llvm-svn: 145410
* Add protection from min/max macrosHoward Hinnant2011-11-291-0/+2
| | | | llvm-svn: 145407
* Windows support by Ruben Van Boxem.Howard Hinnant2011-10-171-0/+2
| | | | llvm-svn: 142235
* Fixed PR10574: http://llvm.org/bugs/show_bug.cgi?id=10574Howard Hinnant2011-08-121-4/+16
| | | | llvm-svn: 137522
* Optimizing valarray::operator=(some-valarray-expression)Howard Hinnant2011-07-271-0/+17
| | | | llvm-svn: 136291
* _STD -> _VSTD to avoid macro clash on windowsHoward Hinnant2011-06-301-9/+9
| | | | llvm-svn: 134190
* license changeHoward Hinnant2010-11-161-2/+2
| | | | llvm-svn: 119395
* visibility-decoration sweep completed.Howard Hinnant2010-09-231-290/+294
| | | | llvm-svn: 114685
* Changed __config to react to all of clang's currently documented has_feature ↵Howard Hinnant2010-09-041-28/+28
| | | | | | flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature. llvm-svn: 113086
* Fixing whitespace problemsHoward Hinnant2010-08-221-34/+34
| | | | llvm-svn: 111750
* Wiped out some non-ascii characters that snuck into the copyright.Howard Hinnant2010-05-111-1/+1
| | | | llvm-svn: 103516
* libcxx initial importHoward Hinnant2010-05-111-0/+4738
llvm-svn: 103490
OpenPOWER on IntegriCloud