summaryrefslogtreecommitdiffstats
path: root/libcxx/include
Commit message (Collapse)AuthorAgeFilesLines
...
* Add missing _v traits. is_bind_expression_v, is_placeholder_v and ↵Marshall Clow2016-09-222-0/+22
| | | | | | uses_allocator_v llvm-svn: 282126
* Fix signatures of fallback tow(upper|lower)_l.Dan Albert2016-09-191-2/+2
| | | | | | | | | | | | | | Summary: These functions take and return wint_t, not int: http://pubs.opengroup.org/onlinepubs/9699919799/functions/towupper.html Reviewers: mclow.lists, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24743 llvm-svn: 281936
* [libc++] Fix extern template visibility for WindowsShoaib Meenai2016-09-191-1/+10
| | | | | | | | | | On Windows, marking an `extern template class` declaration as exported actually forces an instantiation, which is not the desired behavior. Instead, the actual explicit instantiations need to be exported. Differential Revision: https://reviews.llvm.org/D24679 llvm-svn: 281925
* Replace __ANDROID__ with __BIONIC__.Dan Albert2016-09-192-8/+13
| | | | | | | | | | | | | | | Summary: None of these checks are specific to Android devices. If libc++ was used with Bionic on a normal Linux system these checks would still be needed. Reviewers: mclow.lists, EricWF Subscribers: compnerd, tberghammer, danalbert, srhines, cfe-commits Differential Revision: https://reviews.llvm.org/D24690 llvm-svn: 281921
* [libc++] Fix inline attribute for non-MSVC WindowsShoaib Meenai2016-09-161-3/+9
| | | | | | | | | gcc and clang in gcc compatibility mode do not accept __forceinline. Use the gcc attribute for them instead. Differential Revision: https://reviews.llvm.org/D24678 llvm-svn: 281766
* Move _LIBCPP_INLINE_VISIBILITY to first declaration in <propagate_const>Eric Fiselier2016-09-161-4/+8
| | | | llvm-svn: 281692
* Move _LIBCPP_INLINE_VISIBILITY to first declaration in sstream.Eric Fiselier2016-09-161-28/+26
| | | | llvm-svn: 281691
* 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
* Move inline attributes in filesystem to first declarationEric Fiselier2016-09-161-3/+7
| | | | llvm-svn: 281683
* [libc++] Add _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY to support GCC ABI ↵Eric Fiselier2016-09-165-370/+193
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | compatibility Summary: GCC and Clang handle visibility attributes on the out-of-line definition of externally instantiated templates differently. For example in the reproducer below Clang will emit both 'foo' and 'bar' with default visibility while GCC only emits a non-hidden 'foo'. ``` // RUN: g++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out // RUN: clang++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out #define INLINE_VISIBILITY __attribute__((visibility("hidden"), always_inline)) template <class T> struct Foo { void foo(); void bar(); }; template <class T> void Foo<T>::foo() {} template <class T> inline INLINE_VISIBILITY void Foo<T>::bar() {} template struct Foo<int>; ``` This difference creates ABI incompatibilities between Clang and GCC built dylibs. Specifically GCC built dylibs lack definitions for various member functions of `basic_string`, `basic_istream`, `basic_ostream`, `basic_iostream`, and `basic_streambuf` (All of these types are externally instantiated). Surprisingly these missing symbols don't cause many problems because the functions are marked `always_inline` therefore the dylib definition is rarely needed. However when an out-of-line definition is required then GCC built dylibs will fail to link. For example [GCC built dylibs cannot build Clang](http://stackoverflow.com/questions/39454262/clang-build-errors). This patch works around this issue by adding `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` which is used to mark externally instantiated member functions as always inline. When building the library `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` sets the symbol's visibility to "default" instead of "hidden", otherwise it acts exactly the same as `_LIBCPP_INLINE_VISIBILITY`. After applying this patch GCC dylibs now contain: * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7sungetcEv` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5gbumpEi` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7sungetcEv` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9sputbackcEc` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERNS_15basic_streambufIwS2_EE` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_9basic_iosIwS2_EES6_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setpEPcS4_` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6snextcEv` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE4swapERS3_` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE4swapERS3_` * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcm` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_8ios_baseES5_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9pubsetbufEPcl` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekoffExNS_8ios_base7seekdirEj` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_9basic_iosIwS2_EES6_E` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5pbumpEi` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpENS_4fposI11__mbstate_tEE` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE7getlineEPcl` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetcEv` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERNS_15basic_streambufIcS2_EE` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_8ios_baseES5_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8in_availEv` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_8ios_baseES5_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6sbumpcEv` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_9basic_iosIcS2_EES6_E` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERc` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6snextcEv` * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEmw` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE7getlineEPwl` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5tellpEv` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERw` * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEmc` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7pubsyncEv` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getEPcl` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_9basic_iosIcS2_EES6_E` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7pubsyncEv` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputcEc` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpExNS_8ios_base7seekdirE` * `_ZNKSt3__115basic_streambufIcNS_11char_traitsIcEEE6getlocEv` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5gbumpEi` * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEE4swapERS3_` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpENS_4fposI11__mbstate_tEE` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5tellpEv` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRS3_S4_E` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getEPwl` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRS3_S4_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setgEPcS4_S4_` * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwmm` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setgEPwS4_S4_` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8pubimbueERKNS_6localeE` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE4swapERS3_` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekposENS_4fposI11__mbstate_tEEj` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5pbumpEi` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetcEv` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE4swapERS3_` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekposENS_4fposI11__mbstate_tEEj` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputnEPKcl` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpExNS_8ios_base7seekdirE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetnEPwl` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_8ios_baseES5_E` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setpEPwS4_` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetnEPcl` * `_ZNKSt3__115basic_streambufIwNS_11char_traitsIwEEE6getlocEv` * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8pubimbueERKNS_6localeE` * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8in_availEv` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcmm` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6sbumpcEv` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekoffExNS_8ios_base7seekdirEj` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRS3_S4_E` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9sputbackcEw` * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwm` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputnEPKwl` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRS3_S4_E` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9pubsetbufEPwl` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputcEw` This patch has no effect on Clang based builds. Reviewers: mclow.lists, eugenis, danalbert, jroelofs, EricWF Subscribers: beanz, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D24600 llvm-svn: 281681
* [libc++] Fix and document visibility attributes for Clang, GCC and Windows.Eric Fiselier2016-09-1510-148/+143
| | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes a number of problems with the visibility macros across GCC (on Unix) and Windows (DLL import/export semantics). All of the visibility macros are now documented under `DesignDocs/VisibilityMacros.rst`. Now I'll no longer forget the subtleties of each! This patch adds two new visibility macros: * `_LIBCPP_ENUM_VIS` for controlling the typeinfo of enum types. Only Clang supports this. * `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS` for redefining visibility on explicit instantiation declarations. Clang and Windows require this. After applying this patch GCC only emits one -Wattribute warning opposed to 30+. Reviewers: mclow.lists, EricWF Subscribers: beanz, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D24602 llvm-svn: 281673
* [libc++] Avoid <memory> include in locale_win32.hShoaib Meenai2016-09-151-5/+1
| | | | | | | | | | | | | | | | | | | | | | | When `_LIBCPP_NO_EXCEPTIONS` is defined, we end up with compile errors when targeting MSVCRT: * Code includes `<new>` * `<new>` includes `<cstdlib>` in order to get `abort` * `<cstdlib>` includes `<stdlib.h>`, _before_ the `using ::abort` * `<stdlib.h>` includes `locale_win32.h` * `locale_win32.h` includes `<memory>` * `<memory>` includes `<stdexcept>` * `<stdexcept>` includes `<cstdlib` for `abort`, but that inclusion gets (correctly) ignored because of header guards * `<stdexcept>` references `_VSTD::abort`, which isn't declared The easiest solution is to make `locale_win32.h` not include `<memory>`, by removing the use of `unique_ptr` and manually restoring the locale instead. Differential Revision: https://reviews.llvm.org/D24374 llvm-svn: 281641
* Revert r280944 - Added 'inline' attribute to basic_string's destructorEric Fiselier2016-09-141-1/+0
| | | | | | | | | | | | | | | | | | | | This patch causes a couple of issues: 1) It triggers http://llvm.org/PR30341. Although the bug is not truly a libc++ bug it breaks the LLVM build using libc++. Reverting this patch is only a temporary workaround until Clang is fixed. 2) It adds yet another ABI incompatibility when libc++.so is compiled with GCC. Specifically GCC doesn't ignore the _LIBCPP_INLINE_VISIBILITY on the out-of-line definition when compiling the dylib. This causes the externally instantiated ~basic_string symbol to have hidden visibility. This patch should be recommitted after addressing (1) and (2). (2) can be fixed by adding _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY which is defined as __attribute__((visibility("default"), always_inline)) as opposed to _LIBCPP_INLINE_VISIBILITY which makes the symbol hidden. llvm-svn: 281562
* [libcxx] Fix gcc builds.Asiri Rathnayake2016-09-131-2/+13
| | | | | | | Step around a gcc pre-processor defect which causes it to fail to parse the __has_include macro check. llvm-svn: 281310
* config: Use _LIBCPP_TYPE_VIS_ONLY with enum classShoaib Meenai2016-09-121-1/+1
| | | | | | | | | | | An enum class has associated type info. In the Microsoft ABI, type info is emitted in the COMDAT section and isn't exported, so clang rightfully complains about __declspec(dllexport) being unused for an enum class. On other platforms, we still want to export the type info. Differential Revision: https://reviews.llvm.org/D24065 llvm-svn: 281264
* config: Fix typo in commentShoaib Meenai2016-09-121-1/+1
| | | | | | Testing commit access. NFC. llvm-svn: 281250
* [libcxx] Introduce an externally-threaded libc++ variant.Asiri Rathnayake2016-09-114-46/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch further decouples libc++ from pthread, allowing libc++ to be built against other threading systems. There are two main use cases: - Building libc++ against a thread library other than pthreads. - Building libc++ with an "external" thread API, allowing a separate library to provide the implementation of that API. The two use cases are quite similar, the second one being sligtly more de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API enables both kinds of builds. One needs to place an <__external_threading> header file containing an implementation of the "libc++ thread API" declared in the <__threading_support> header. For the second use case, the implementation of the libc++ thread API can delegate to a custom "external" thread API where the implementation of this external API is provided in a seperate library. This mechanism allows toolchain vendors to distribute a build of libc++ with a custom thread-porting-layer API (which is the "external" API above), platform vendors (recipients of the toolchain/libc++) are then required to provide their implementation of this API to be linked with (end-user) C++ programs. Note that the second use case still requires establishing the basic types that get passed between the external thread library and the libc++ library (e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources won't compile otherwise). It should also be noted that the second use case can have a slight performance penalty; as all the thread constructs need to cross a library boundary through an additional function call. When the header <__external_threading> is omitted, libc++ is built with the "libc++ thread API" (declared in <__threading_support>) as the "external" thread API (basic types are pthread based). An implementation (pthread based) of this API is provided in test/support/external_threads.cpp, which is built into a separate DSO and linked in when running the libc++ test suite. A test run therefore demonstrates the second use case (less the intermediate custom API). Differential revision: https://reviews.llvm.org/D21968 Reviewers: bcraig, compnerd, EricWF, mclow.lists llvm-svn: 281179
* support: clean up MSVC supportSaleem Abdulrasool2016-09-081-20/+2
| | | | | | | | | | | Visual Studio 2013 (CRT version 12) added support for many C99 long long and long double functions. Visual Studio 2015 (CRT version 14) increased C99 and C11 compliance further. Since we don't support Visual Studio versions older than 2013, we can considerably clean up the support header. Patch by Shoaib Meenai! llvm-svn: 280988
* Added 'inline' attribute to basic_string's destructorAditya Kumar2016-09-081-0/+1
| | | | | | | | | | | | | | | Author: laxmansole Reviewers: howard.hinnant mclow.lists Subscribers: EricWF, flyingforyou, evandro Differential Revision: https://reviews.llvm.org/D22834 Currently basic_string's destructor is not getting inlined. So adding 'inline' attribute to ~basic_string(). Worked in collaboration with Aditya Kumar. llvm-svn: 280944
* Fix PR#30303 - no matching function for call to '__ptr_in_range'Marshall Clow2016-09-071-1/+7
| | | | llvm-svn: 280779
* Fix PR30260 - optional<const T> not working.Eric Fiselier2016-09-071-14/+19
| | | | | | | | | | This patch fixes PR30260 by using a (void*) cast on the placement argument to placement new to casts away the const. See also http://llvm.org/PR30260. As a drive by change this patch also changes the header guard for <experimental/optional> to _LIBCPP_EXPERIMENTAL_OPTIONAL from _LIBCPP_OPTIONAL. llvm-svn: 280775
* Try 2 - Remove <cstdlib> include from `<exception>`Eric Fiselier2016-09-064-4/+9
| | | | | | | | | | | 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
* Revert r280743 and r280745. Remove <cstdlib> include from `<exception>`Eric Fiselier2016-09-062-1/+4
| | | | | | | Apparently I missed a number of additional include which need to be added. Reverting so I can recommit as a single patch with all of the required includes. llvm-svn: 280752
* Add missing <cstdlib> include. Sorry about the bot breakageEric Fiselier2016-09-061-0/+1
| | | | llvm-svn: 280745
* Remove unneeded includes in <exception> after removing __libcpp_throwEric Fiselier2016-09-061-4/+0
| | | | llvm-svn: 280743
* Fix Bug 30240 - std::string: append(first, last) error when aliasing. Add ↵Marshall Clow2016-09-051-13/+33
| | | | | | test cases for append/insert/assign/replace while we're at it, and fix a similar bug in insert. llvm-svn: 280643
* [libcxx] Fix a data race in call_onceKuba Brecka2016-09-042-2/+14
| | | | | | | | call_once is using relaxed atomic load to perform double-checked locking, which contains a data race. The fast-path load has to be an acquire atomic load. Differential Revision: https://reviews.llvm.org/D24028 llvm-svn: 280621
* Fix PR30202 - notify_all_at_thread_exit seg faults if run from a raw pthread ↵Eric Fiselier2016-09-031-16/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | context. Summary: This patch allows threads not created using `std::thread` to use `std::notify_all_at_thread_exit` by ensuring the TL state has been initialized within `std::notify_all_at_thread_exit`. Additionally this patch "fixes" a potential oddity in `__thread_local_pointer::reset(pointer)`, which would previously delete the old thread local data. However there should *never* be old thread local data because pthread *should* null it out on thread exit. Unfortunately it's possible that pthread failed to do this according to the spec: > > Upon key creation, the value NULL shall be associated with the new key in all active threads. Upon thread creation, the value NULL shall be associated with all defined keys in the new thread. > > An optional destructor function may be associated with each key value. At thread exit, if a key value has a non-NULL destructor pointer, and the thread has a non-NULL value associated with that key, the value of the key is set to NULL, and then the function pointed to is called with the previously associated value as its sole argument. The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits. > > If, after all the destructors have been called for all non-NULL values with associated destructors, there are still some non-NULL values with associated destructors, then the process is repeated. If, after at least {PTHREAD_DESTRUCTOR_ITERATIONS} iterations of destructor calls for outstanding non-NULL values, there are still some non-NULL values with associated destructors, implementations may stop calling destructors, or they may continue calling destructors until no non-NULL values with associated destructors exist, even though this might result in an infinite loop. However if pthread fails to delete the value it is probably incorrect for us to do it. Destroying the value performs all of the "at thread exit" actions registered with it but we are way past "at thread exit". Reviewers: mclow.lists, bcraig, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24159 llvm-svn: 280588
* Define _LIBCPP_SAFE_STATIC ↵Eric Fiselier2016-09-031-0/+6
| | | | | | __attribute__((require_constant_initialization)), and apply it to memory_resource llvm-svn: 280561
* Avoid narrowing warnings in __bitset constructorDimitry Andric2016-09-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | When <bitset> is compiled with warnings enabled, on a platform where size_t is 4 bytes, it results in errors similar to: bitset:265:16: error: non-constant-expression cannot be narrowed from type 'unsigned long long' to '__storage_type' (aka 'unsigned int') in initializer list [-Wc++11-narrowing] : __first_{__v, __v >> __bits_per_word} ^~~ bitset:676:52: note: in instantiation of member function 'std::__1::__bitset<2, 53>::__bitset' requested here bitset(unsigned long long __v) _NOEXCEPT : base(__v) {} ^ Fix these by casting the initializer list elements to __storage_type. Reviewers: mclow.lists, EricWF Differential Revision: https://reviews.llvm.org/D23960 llvm-svn: 280543
* cstdio: limit gets to CRT versions below 14Saleem Abdulrasool2016-09-011-1/+5
| | | | | | | | | | | | Microsoft removed gets from the CRT in Visual Studio 2015 onwards [1]. Attempting to reference it when targeting CRT versions 14 and above will cause compile errors. [1] https://msdn.microsoft.com/en-us/library/2029ea5f.aspx Patch by Shoaib Meenai! llvm-svn: 280417
* [CMake] NFC. Fixing spelling from r280400Chris Bieneman2016-09-011-1/+1
| | | | | | Doh! llvm-svn: 280406
* [CMake] Don't copy headers on fully standaloneChris Bieneman2016-09-011-1/+1
| | | | | | | | In r280108 I tried to make the headers copy relative to LLVM_BINARY_DIR, and the intent was that it would only happen on in-tree builds or runtimes directory builds. It didn't actually work that way. This patch adds a check for CMAKE_SOURCE_DIR being equal to CMAKE_CURRENT_SOURCE_DIR. In this case we set a variable LIBCXX_USING_INSTLLED_LLVM. This doesn't necessarily mean the LLVM is installed (it could be a build directory), but it means we need to treat the LLVM directory as read-only. llvm-svn: 280400
* [CMake] Copy headers relative to LLVM_BINARY_DIRChris Bieneman2016-08-301-5/+7
| | | | | | | | | | | | Summary: This copy phase is only needed for in-tree builds, so we should be copying to the LLVM build directory's include dir instead of the sub-project include dir. Reviewers: bogner, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24015 llvm-svn: 280108
* Fix or suppress GCC warnings during build.Eric Fiselier2016-08-294-2/+17
| | | | | | | | | | | | | | | | | | | | Summary: Currently a number of GCC warnings are emitted when building libc++. This patch fixes or ignores all of them. The primary changes are: * Work around strict aliasing issues in `typeinfo::hash_code()` by using __attribute__((may_alias)). However I think a non-aliasing `hash_code()` implementation is possible. Further investigation needed. * Add `_LIBCPP_UNREACHABLE()` to switch in `strstream.cpp` to avoid -Wpotentially-uninitialized. * Fix -Wunused-value warning in `__all` by adding a void cast. * Ignore -Wattributes for now. There are a number of real attribute issues when using GCC but enabling the warning is too noisy. * Ignore -Wliteral-suffix since it warns about the use of reserved identifiers. Note Only GCC 7.0 supports disabling this warning. * Ignore -Wc++14-compat since it warns about the sized new/delete overloads. Reviewers: EricWF Differential Revision: https://reviews.llvm.org/D24003 llvm-svn: 280007
* Fix pair::operator=(TupleLike&&).Eric Fiselier2016-08-291-1/+1
| | | | | | | | | | | This assignment operator was previously broken since the SFINAE always resulted in substitution failure. This caused assignments to turn into copy construction + assignment. This patch was originally committed as r279953 but was reverted due to warnings in the test-suite. This new patch corrects those warnings. llvm-svn: 279955
* Revert r279953 - Fix pair::operator=(TupleLike&&)Eric Fiselier2016-08-291-1/+1
| | | | | | | The test emits warnings causing the test-suite to fail. Since I want this patch merged into 3.9 I'll recommit it with a clean test. llvm-svn: 279954
* Fix pair::operator=(TupleLike&&).Eric Fiselier2016-08-291-1/+1
| | | | | | | | This assignment operator was previously broken since the SFINAE always resulted in substitution failure. This caused assignments to turn into copy construction + assignment. llvm-svn: 279953
* Implement C++17 std::sample.Eric Fiselier2016-08-282-58/+83
| | | | | | | | This patch implements the std::sample function added to C++17 from LFTS. It also removes the std::experimental::sample implementation which now forwards to std::sample. llvm-svn: 279948
* Mark LWG 2716 as complete - shuffle and sample disallows lvalue URNGs.Eric Fiselier2016-08-281-0/+3
| | | | | | | | | | | Libc++'s implementation of shuffle and sample already support lvalue and rvalue RNG's. This patch adds tests for both categories and marks the issue as complete. This patch also contains drive-by change for std::experimental::sample which improves the diagnostics produced when the correct iterator categories are not supplied. llvm-svn: 279947
* Implement LWG 2711. Constrain path members.Eric Fiselier2016-08-281-0/+3
| | | | llvm-svn: 279945
* Avoid embedded preprocessor directives in __treeDimitry Andric2016-08-271-5/+8
| | | | | | | | | | Similar to rL242623, move C++ version checks outside of _NOEXCEPT_() macro invocation argument lists, to avoid "embedding a directive within macro arguments has undefined behavior" warnings. Differential Revision: https://reviews.llvm.org/D23961 llvm-svn: 279926
* Add attribute noreturn to functions that throwAditya Kumar2016-08-272-1/+4
| | | | | | | | | Reviewers: mclow.lists, EricWF, howard.hinnant, sebpop Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D21232 llvm-svn: 279903
* Followon to r279744. Find the other exception types and make __throw_XXX ↵Marshall Clow2016-08-257-31/+37
| | | | | | routines (and call them). Remove the generic __libcpp_throw routine, since no one uses it anymore. llvm-svn: 279763
* Remove duplicate inlineMarshall Clow2016-08-251-1/+1
| | | | llvm-svn: 279746
* Add an _LIBCPP_NORETURN inline function named __throw_XXX for each exception ↵Marshall Clow2016-08-2522-194/+214
| | | | | | 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
* Remove trailing WS [NFC]Aditya Kumar2016-08-251-15/+15
| | | | llvm-svn: 279731
* [CMake] Be more consistent about naming targets and componentsChris Bieneman2016-08-241-6/+9
| | | | | | | | | | | | | | | Summary: The point of this patch is to have a consistent convention for naming build, check and install targets so that the targets can be constructed from the project name. This change renames a bunch of CMake components and targets from libcxx to cxx. For each renamed target I've added a convenience target that matches the old target name and depends on the new target. This will preserve function of the old targets so that the change doesn't break the world. We can evaluate if it is worth removing the extra targets later. Reviewers: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D23699 llvm-svn: 279675
* make the associative containers do the right thing for ↵Marshall Clow2016-08-171-1/+5
| | | | | | propogate_on_container_assignment. Fixes bug #29001. Tests are only for <map> right now - more complete tests will come when we revamp our allocator testing structure. llvm-svn: 279008
* Support allocators with explicit conversion constructors. Fixes bug #29000Marshall Clow2016-08-172-26/+26
| | | | llvm-svn: 278904
OpenPOWER on IntegriCloud