summaryrefslogtreecommitdiffstats
path: root/libcxx/include/__config_site.in
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Take 2: Integrate the PSTL into libc++Louis Dionne2019-08-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+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/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* Rework std::type_info definition to support systems without fullyEric Fiselier2019-05-291-0/+1
| | | | | | | | | | | | | | | | | | merged type info names. Previously std::type_info always expected type info string to be unique. But this isn't always the case. Like when -Bsymbolic is passed to the linker or due to llvm.org/PR37398. This patch adds the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT CMake option which, when specified, overrides the default configuration for the library. The current defaults still assume unique names even though this isn't strictly correct for ELF binaries. We should consider changing the default in a follow up commit. llvm-svn: 361913
* 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
* Make libc++'s versioning namespace customizableEric Fiselier2018-10-301-0/+1
| | | | | | | | | | | | | | | | | Summary: This patch makes the versioning namespace libc++ uses customizable by the user using `-DLIBCXX_ABI_NAMESPACE=__foo`. This allows users to build custom versions of libc++ which can be linked into binaries with other libc++ versions without causing symbol conflicts or ODR issues. Reviewers: mclow.lists, ldionne Reviewed By: ldionne Subscribers: kristina, smeenai, mgorny, phosek, libcxx-commits Differential Revision: https://reviews.llvm.org/D53879 llvm-svn: 345657
* [libcxx] By default, do not use internal_linkage to hide symbols from the ABILouis Dionne2018-08-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and we expect this may be the case in other projects built in debug mode too. Instead, unless users explicitly ask for internal_linkage, we use always_inline like we used to. In the future, when we have a solution that allows us to drop always_inline without falling back on internal_linkage, we can replace always_inline by that. Note that this commit introduces a change in contract for existing libc++ users: by default, libc++ used to guarantee that TUs built with different versions of libc++ could be linked together. With the introduction of the _LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built with different libc++ versions are not guaranteed to link. This is a change in contract but not a change in behavior, since the current implementation still allows linking TUs built with different libc++ versions together. Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk Subscribers: christof, cfe-commits Differential Revision: https://reviews.llvm.org/D50652 llvm-svn: 339874
* [cmake] Add a config option LIBCXX_HAS_WIN32_THREAD_API for enforcing win32 ↵Martin Storsjo2018-01-051-0/+1
| | | | | | | | | | | | | | | | threads This allows keeping libcxx using win32 threads even if a version of pthread.h is installed. This matches the existing cmake option LIBCXX_HAS_PTHREAD_API. Also add missing documentation about the internal define _LIBCPP_HAS_THREAD_API_WIN32. Differential Revision: https://reviews.llvm.org/D41764 llvm-svn: 321896
* [libc++] Support Microsoft ABI without vcruntime headersShoaib Meenai2017-10-091-0/+1
| | | | | | | | | | | | | | | | | 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
* [libc++] Clarify names of ABI forcing macrosShoaib Meenai2017-10-051-2/+2
| | | | | | | | | Make it clear that these are intended only to force a specific ABI when the autodetection would give the wrong result by renaming the cmake options and adding separate forcing macros, as suggested by EricWF in the post-commit review of r314949 and further discussed on IRC. llvm-svn: 314965
* [libc++] Allow users to explicitly specify ABIShoaib Meenai2017-10-041-0/+2
| | | | | | | | | | libc++'s current heuristic for detecting Itanium vs. Microsoft ABI falls short in some cases. For example, it will detect windows-itanium targets as using the Microsoft ABI, since they set `_MSC_VER` (for compatibility with Microsoft headers). Leave the current heuristic in place by default but also allow users to explicitly specify the ABI if need be. llvm-svn: 314949
* [libc++] Add site config option for ABI macrosShoaib Meenai2017-10-041-0/+2
| | | | | | | | | | | | | | | | | Some ABI macros affect headers, so it's nice to have a site config option for them. Add a LIBCXX_ABI_DEFINES cmake macro to allow specifying a list of ABI macros to define in the site config. The primary design constraint (as discussed with Eric on IRC a while back) was to not have to repeat the ABI macro names in cmake, which only leaves a free-form cmake list as an option. A somewhat unfortunate consequence is that we can't verify that the ABI macros being defined actually exist, though we can at least perform some basic sanity checking, since all the ABI macros begin with _LIBCPP_ABI_. Differential Revision: https://reviews.llvm.org/D36719 llvm-svn: 314946
* [libc++] Cleanup and document <__threading_support>Eric Fiselier2017-01-061-0/+1
| | | | | | | | | | | | | | | Summary: This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses. The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API. Reviewers: compnerd, rmaprath Subscribers: smeenai, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D28316 llvm-svn: 291275
* [libc++] Add _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONSShoaib Meenai2016-12-051-1/+1
| | | | | | | | | | | It's useful to be able to disable visibility annotations entirely; for example, if we're building libc++ static to include in another library, and we don't want any libc++ functions getting exported out of that library. This is a generalization of _LIBCPP_DISABLE_DLL_IMPORT_EXPORT. Differential Revision: https://reviews.llvm.org/D26934 llvm-svn: 288690
* Expect DLL builds on Windows by default and require a custom __config for staticEric Fiselier2016-09-261-0/+1
| | | | | | | | | | | | | | | | | | | builds. On Windows the __declspec(dllimport) and __declspec(dllexport) attributes require linking to a DLL, not a static library. Previously these annotations were disabled by default unless _LIBCPP_DLL was defined. However the DLL configuration is probably the more common one, so it should be supported by default. This patch enables import/export attributes by default and adds a _LIBCPP_DISABLE_DLL_IMPORT_EXPORT macro which can be used to disable this behavior. If libc++ is built as a static library on Windows then a custom __config header will be generated that predefines this macro. This patch is based off work by Shoaib Meenai. llvm-svn: 282449
* [libcxx] Introduce an externally-threaded libc++ variant.Asiri Rathnayake2016-09-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [libcxx] Allow explicit pthread opt-inBen Craig2016-05-251-0/+1
| | | | | | | | | | | | | | | The existing pthread detection code in __config is pretty good for common operating systems. It doesn't allow cmake-time choices to be made for uncommon operating systems though. This change adds the LIBCXX_HAS_PTHREAD_API cmake flag, which turns into the _LIBCPP_HAS_THREAD_API_PTHREAD preprocessor define. This is a name change from the old _LIBCPP_THREAD_API_PTHREAD. The lit tests want __config_site.in variables to have a _LIBCPP_HAS prefix. http://reviews.llvm.org/D20573 llvm-svn: 270735
* Add initial support for the MUSL C library.Vasileios Kalintiris2015-11-091-1/+2
| | | | | | | | | | | | | | | | | | | Summary: This patch adds the LIBCXX_LIBC_IS_MUSL cmake option to allow the building of libcxx with the Musl C library. The option is necessary as Musl does not provide any predefined macro in order to test for its presence, like GLIBC. Most of the changes specify the correct path to choose through the various #if/#else constructs in the locale code. Depends on D13407. Reviewers: mclow.lists, jroelofs, EricWF Subscribers: jfb, tberghammer, danalbert, srhines, cfe-commits Differential Revision: http://reviews.llvm.org/D13673 llvm-svn: 252457
* ABI versioning macros for libc++.Evgeniy Stepanov2015-10-131-0/+2
| | | | | | | | C++ macros and CMake options that specify the default ABI version of the library, and can be overridden to pick up new ABI-changing features. llvm-svn: 250254
* [libcxx] Capture configuration information when installing the libc++ headersEric Fiselier2015-10-131-0/+20
Summary: Hi all, This patch is a successor to D11963. However it has changed dramatically and I felt it would be best to start a new review thread. Please read the design documentation added in this patch for a description of how it works. Reviewers: mclow.lists, danalbert, jroelofs, EricWF Subscribers: vkalintiris, rnk, ed, espositofulvio, asl, eugenis, cfe-commits Differential Revision: http://reviews.llvm.org/D13407 llvm-svn: 250235
OpenPOWER on IntegriCloud