| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[runtimes] Use LLVM libunwind from libc++abi by default (#77687) I recently came across LIBCXXABI_USE_LLVM_UNWINDER and was surprised to notice it was disabled by default. Since we build libunwind by default and ship it in the LLVM toolchain, it would seem to make sense that libc++ and libc++abi rely on libunwind for unwinding instead of using the system-provided unwinding library (if any). Most importantly, using the system unwinder implies that libc++abi is ABI compatible with that system unwinder, which is not necessarily the case. Hence, it makes a lot more sense to instead default to using the known-to-be-compatible LLVM unwinder, and let vendors manually select a different unwinder if desired. As a follow-up change, we should probably apply the same default to compiler-rt. Differential Revision: https://reviews.llvm.org/D150897 Fixes #77662 rdar://120801778 | 2 年前 | |
[runtimes] Always define cxx_shared, cxx_static & other targets (#80007) This patch always defines the cxx_shared, cxx_static & other top-level targets. However, they are marked as EXCLUDE_FROM_ALL when we don't want to build them. Simply declaring the targets should be of no harm, and it allows other projects to mention these targets regardless of whether they end up being built or not. This patch basically moves the definition of e.g. cxx_shared out of the if (LIBCXX_ENABLE_SHARED) and instead marks it as EXCLUDE_FROM_ALL conditionally on whether LIBCXX_ENABLE_SHARED is passed. It then does the same for libunwind and libc++abi targets. I purposefully avoided to reformat the files (which now has inconsistent indentation) because I wanted to keep the diff minimal, and I know this is an area of the code where folks may have downstream diffs. I will re-indent the code separately once this patch lands. This is a reapplication of 79ee0342dbf0, which was reverted in a3539090884c because it broke the TSAN and the Fuchsia builds. Resolves #77654 Differential Revision: https://reviews.llvm.org/D134221 | 1 年前 | |
[LLVM] Fix GPU build of libcxx/compiler-rt libraries Summary: Recent changes altered the name without updating this, add it in and also tell the builtins build that C++ compilers work because it seems to require that now. | 1 年前 | |
[libc++] Expand Android libc++ test config files (#142846) Parameterize (and rename) existing libc++/libc++abi test configuration files for the Android NDK to work for both the NDK and platform. Android LLVM downstream seeks to test libc++ for both the NDK and platform build (currently only testing the NDK), which will use almost identical test configuration files. The only difference is the name of the libc++ shared object used. Because of this we parameterize the current test files (for both libc++ and libc++abi) with the existing LIBCXX_SHARED_OUTPUT_NAME cmake variable, and rename the file accordingly. | 1 年前 | |
[libc++] Run the Lit test suite against an installed version of the library (#96910) We always strive to test libc++ as close as possible to the way we are actually shipping it. This was approximated reasonably well by setting up the minimal driver flags when running the test suite, however we were running the test suite against the library located in the build directory. This patch improves the situation by installing the library (the headers, the built library, modules, etc) into a fake location and then running the test suite against that fake "installation root". This should open the door to getting rid of the temporary copy of the headers we make during the build process, however this is left for a future improvement. Note that this adds quite a bit of verbosity whenever running the test suite because we install the headers beforehand every time. We should be able to override this to silence it, however CMake doesn't currently give us a way to do that, see https://gitlab.kitware.com/cmake/cmake/-/issues/26085. | 1 年前 | |
[libc++] Enable Clang modules in most of the CI runs (#160251) Enabling modules makes the CI quite a bit faster with basically no downsides. The non-modules build is still tested through the generic-cxxab configurations, but most of the other CI runs on platforms with modules support now use modules. | 9 个月前 | |
[libcxx][CI] Use lld for everything in the ARM picolib builds (#158320) Our host compiler is a clang install that will default to ld if not told otherwise. We were telling meson to use lld, but the way that we did it was outdated, which lead to picolib producing a linker script that lld could not use. The tests were in fact linking with ld instead. Using the c_ld setting fixes this problem. See: https://mesonbuild.com/Machine-files.html#binaries Then to use lld in tests we need -fuse-ld=lld in the config files. Some of these options were not needed for clang 19.1.7, but were for clang 21.1.1. We will soon update to 21.1.1 so I have included all of the required options in this PR. | 10 个月前 | |
[libc++] Enable Clang modules in most of the CI runs (#160251) Enabling modules makes the CI quite a bit faster with basically no downsides. The non-modules build is still tested through the generic-cxxab configurations, but most of the other CI runs on platforms with modules support now use modules. | 9 个月前 | |
[libc++] Enable Clang modules in most of the CI runs (#160251) Enabling modules makes the CI quite a bit faster with basically no downsides. The non-modules build is still tested through the generic-cxxab configurations, but most of the other CI runs on platforms with modules support now use modules. | 9 个月前 | |
[libc++] Enable Clang modules in most of the CI runs (#160251) Enabling modules makes the CI quite a bit faster with basically no downsides. The non-modules build is still tested through the generic-cxxab configurations, but most of the other CI runs on platforms with modules support now use modules. | 9 个月前 | |
[libc++][hardening] Deprecate _LIBCPP_ENABLE_ASSERTIONS. _LIBCPP_ENABLE_ASSERTIONS was used to enable the "safe" mode in libc++. Libc++ now provides the hardened mode and the debug mode that replace the safe mode. For backward compatibility, enabling _LIBCPP_ENABLE_ASSERTIONS now enables the hardened mode. Note that the hardened mode provides a narrower set of checks than the previous "safe" mode (only security-critical checks that are performant enough to be used in production). Differential Revision: https://reviews.llvm.org/D154997 | 2 年前 | |
[libc++] Add Unstable ABI CI run Reviewed By: ldionne, #libc, Mordante Spies: mgorny, Mordante, libcxx-commits, arichardson Differential Revision: https://reviews.llvm.org/D118725 | 4 年前 | |
[libc++][CI] Removes an ASAN work-around. With the underlying bug fixed the work-around should no longer be needed. Reviewed By: #libc, philnik Differential Revision: https://reviews.llvm.org/D157779 | 2 年前 | |
[libc++][C++03] Use __cxx03/ headers in C++03 mode (#109002) This patch implements the forwarding to frozen C++03 headers as discussed in https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the RFC, we initially proposed selecting the right headers from the Clang driver, however consensus seemed to steer towards handling this in the library itself. This patch implements that direction. At a high level, the changes basically amount to making each public header look like this: // inside <vector> #ifdef _LIBCPP_CXX03_LANG # include <__cxx03/vector> #else // normal <vector> content #endif In most cases, public headers are simple umbrella headers so there isn't much code in the #else branch. In other cases, the #else branch contains the actual implementation of the header. | 1 年前 | |
[runtimes] Allow passing Lit parameters through CMake This allows passing parameters to the test suites without using LLVM_LIT_ARGS. The problem is that we sometimes want to set some Lit arguments on the CMake command line, but the Lit parameters in a CMake cache file. If the only knob to do that is LLVM_LIT_ARGS, the command-line entry overrides the cache one, and the parameters set by the cache are ignored. This fixes a current issue with the build bots that they completely ignore the 'std' param set by Lit, because other Lit arguments are provided via LLVM_LIT_ARGS on the CMake command-line. | 5 年前 | |
[runtimes] Allow passing Lit parameters through CMake This allows passing parameters to the test suites without using LLVM_LIT_ARGS. The problem is that we sometimes want to set some Lit arguments on the CMake command line, but the Lit parameters in a CMake cache file. If the only knob to do that is LLVM_LIT_ARGS, the command-line entry overrides the cache one, and the parameters set by the cache are ignored. This fixes a current issue with the build bots that they completely ignore the 'std' param set by Lit, because other Lit arguments are provided via LLVM_LIT_ARGS on the CMake command-line. | 5 年前 | |
[runtimes] Allow passing Lit parameters through CMake This allows passing parameters to the test suites without using LLVM_LIT_ARGS. The problem is that we sometimes want to set some Lit arguments on the CMake command line, but the Lit parameters in a CMake cache file. If the only knob to do that is LLVM_LIT_ARGS, the command-line entry overrides the cache one, and the parameters set by the cache are ignored. This fixes a current issue with the build bots that they completely ignore the 'std' param set by Lit, because other Lit arguments are provided via LLVM_LIT_ARGS on the CMake command-line. | 5 年前 | |
[runtimes] Allow passing Lit parameters through CMake This allows passing parameters to the test suites without using LLVM_LIT_ARGS. The problem is that we sometimes want to set some Lit arguments on the CMake command line, but the Lit parameters in a CMake cache file. If the only knob to do that is LLVM_LIT_ARGS, the command-line entry overrides the cache one, and the parameters set by the cache are ignored. This fixes a current issue with the build bots that they completely ignore the 'std' param set by Lit, because other Lit arguments are provided via LLVM_LIT_ARGS on the CMake command-line. | 5 年前 | |
[libc++][modules] Enable installation by default. (#90094) This was suggested during the review of https://github.com/llvm/llvm-project/pull/89413 This does not change the experimental state of modules. | 2 年前 | |
[libc++][modules] Enable installation by default. (#90094) This was suggested during the review of https://github.com/llvm/llvm-project/pull/89413 This does not change the experimental state of modules. | 2 年前 | |
[libc++][modules] Enable installation by default. (#90094) This was suggested during the review of https://github.com/llvm/llvm-project/pull/89413 This does not change the experimental state of modules. | 2 年前 | |
[libc++] Enable Clang modules in most of the CI runs (#160251) Enabling modules makes the CI quite a bit faster with basically no downsides. The non-modules build is still tested through the generic-cxxab configurations, but most of the other CI runs on platforms with modules support now use modules. | 9 个月前 | |
[libc++][hardening] Introduce assertion semantics. (#149459) Assertion semantics closely mimic C++26 Contracts evaluation semantics. This brings our implementation closer in line with C++26 Library Hardening (one particular benefit is that using the observe semantic makes adopting hardening easier for projects). | 11 个月前 | |
[libc++] Enable Clang modules in most of the CI runs (#160251) Enabling modules makes the CI quite a bit faster with basically no downsides. The non-modules build is still tested through the generic-cxxab configurations, but most of the other CI runs on platforms with modules support now use modules. | 9 个月前 | |
[libc++] Enable Clang modules in most of the CI runs (#160251) Enabling modules makes the CI quite a bit faster with basically no downsides. The non-modules build is still tested through the generic-cxxab configurations, but most of the other CI runs on platforms with modules support now use modules. | 9 个月前 | |
[libc++] Enable Clang modules in most of the CI runs (#160251) Enabling modules makes the CI quite a bit faster with basically no downsides. The non-modules build is still tested through the generic-cxxab configurations, but most of the other CI runs on platforms with modules support now use modules. | 9 个月前 | |
[libc++] Enable Clang modules in most of the CI runs (#160251) Enabling modules makes the CI quite a bit faster with basically no downsides. The non-modules build is still tested through the generic-cxxab configurations, but most of the other CI runs on platforms with modules support now use modules. | 9 个月前 | |
[libc++] Add coverage for C++17 and Clang Modules with LSV (#131815) In recent versions of Clang, using -std=c++20 (and later) implies LSV when compiling with modules. This change resulted in making our LSV job redundant with the regular modules job, which uses the latest Standard. This patch increases the coverage of our CI without increasing its cost by pinning the LSV job to use C++17, which normally doesn't use LSV. A related question is whether we should add coverage for non-LSV builds using Clang modules. | 1 年前 | |
[libc++][modules] Adds the C++23 std module. The patch is based on D144994. D151030 added the module definitions for the module std. This patch wires in the module and enables the basic testing. Some notable features are missing: - There is no test that libc++ can be fully imported as a module. - This lacks the parts for the std.compat module. - The module is not shipped with libc++. Implements parts of - P2465R3 Standard Library Modules std and std.compat Reviewed By: ldionne, aaronmondal, #libc Differential Revision: https://reviews.llvm.org/D151814 | 3 年前 | |
[libc++] Enable Clang modules in most of the CI runs (#160251) Enabling modules makes the CI quite a bit faster with basically no downsides. The non-modules build is still tested through the generic-cxxab configurations, but most of the other CI runs on platforms with modules support now use modules. | 9 个月前 | |
[libc++] Enable Clang modules in carve-out CI jobs (#100571) This speeds up the CI a bit (anecdotally ~10%) for those jobs, and it also helps ensure that we are clean w.r.t. Clang modules when we disable some of the carve-outs like no-localization or no-threads. | 1 年前 | |
[libc++] Enable Clang modules in carve-out CI jobs (#100571) This speeds up the CI a bit (anecdotally ~10%) for those jobs, and it also helps ensure that we are clean w.r.t. Clang modules when we disable some of the carve-outs like no-localization or no-threads. | 1 年前 | |
[libc++] Enable Clang modules in carve-out CI jobs (#100571) This speeds up the CI a bit (anecdotally ~10%) for those jobs, and it also helps ensure that we are clean w.r.t. Clang modules when we disable some of the carve-outs like no-localization or no-threads. | 1 年前 | |
[libc++] Enable Clang modules in carve-out CI jobs (#100571) This speeds up the CI a bit (anecdotally ~10%) for those jobs, and it also helps ensure that we are clean w.r.t. Clang modules when we disable some of the carve-outs like no-localization or no-threads. | 1 年前 | |
[libc++] Enable Clang modules in carve-out CI jobs (#100571) This speeds up the CI a bit (anecdotally ~10%) for those jobs, and it also helps ensure that we are clean w.r.t. Clang modules when we disable some of the carve-outs like no-localization or no-threads. | 1 年前 | |
[libc++] Enable Clang modules in carve-out CI jobs (#100571) This speeds up the CI a bit (anecdotally ~10%) for those jobs, and it also helps ensure that we are clean w.r.t. Clang modules when we disable some of the carve-outs like no-localization or no-threads. | 1 年前 | |
[libcxx] Add LIBCXX_HAS_TERMINAL_AVAILABLE CMake option to disable print terminal checks (#99259) Adds a new CMake option called LIBCXX_HAS_TERMINAL_AVAILABLE that prevents us from checking for isatty. | 1 年前 | |
[libc++] Enable Clang modules in carve-out CI jobs (#100571) This speeds up the CI a bit (anecdotally ~10%) for those jobs, and it also helps ensure that we are clean w.r.t. Clang modules when we disable some of the carve-outs like no-localization or no-threads. | 1 年前 | |
[libc++] Enable Clang modules in carve-out CI jobs (#100571) This speeds up the CI a bit (anecdotally ~10%) for those jobs, and it also helps ensure that we are clean w.r.t. Clang modules when we disable some of the carve-outs like no-localization or no-threads. | 1 年前 | |
[libc++] Enable Clang modules in carve-out CI jobs (#100571) This speeds up the CI a bit (anecdotally ~10%) for those jobs, and it also helps ensure that we are clean w.r.t. Clang modules when we disable some of the carve-outs like no-localization or no-threads. | 1 年前 | |
[libc++] Enable Clang modules in carve-out CI jobs (#100571) This speeds up the CI a bit (anecdotally ~10%) for those jobs, and it also helps ensure that we are clean w.r.t. Clang modules when we disable some of the carve-outs like no-localization or no-threads. | 1 年前 | |
[libc++] Enable Clang modules in most of the CI runs (#160251) Enabling modules makes the CI quite a bit faster with basically no downsides. The non-modules build is still tested through the generic-cxxab configurations, but most of the other CI runs on platforms with modules support now use modules. | 9 个月前 | |
[libc++] Enable Clang modules in most of the CI runs (#160251) Enabling modules makes the CI quite a bit faster with basically no downsides. The non-modules build is still tested through the generic-cxxab configurations, but most of the other CI runs on platforms with modules support now use modules. | 9 个月前 | |
[libc++] Enable Clang modules in most of the CI runs (#160251) Enabling modules makes the CI quite a bit faster with basically no downsides. The non-modules build is still tested through the generic-cxxab configurations, but most of the other CI runs on platforms with modules support now use modules. | 9 个月前 | |
[libc++] Enable Clang modules in most of the CI runs (#160251) Enabling modules makes the CI quite a bit faster with basically no downsides. The non-modules build is still tested through the generic-cxxab configurations, but most of the other CI runs on platforms with modules support now use modules. | 9 个月前 | |
[runtimes] Use LLVM libunwind from libc++abi by default (#77687) I recently came across LIBCXXABI_USE_LLVM_UNWINDER and was surprised to notice it was disabled by default. Since we build libunwind by default and ship it in the LLVM toolchain, it would seem to make sense that libc++ and libc++abi rely on libunwind for unwinding instead of using the system-provided unwinding library (if any). Most importantly, using the system unwinder implies that libc++abi is ABI compatible with that system unwinder, which is not necessarily the case. Hence, it makes a lot more sense to instead default to using the known-to-be-compatible LLVM unwinder, and let vendors manually select a different unwinder if desired. As a follow-up change, we should probably apply the same default to compiler-rt. Differential Revision: https://reviews.llvm.org/D150897 Fixes #77662 rdar://120801778 | 2 年前 | |
[LLVM] Fix GPU build of libcxx/compiler-rt libraries Summary: Recent changes altered the name without updating this, add it in and also tell the builtins build that C++ compilers work because it seems to require that now. | 1 年前 | |
[libc++][CMake] Add CMake caches for commonly supported configurations This commit adds CMake caches for the various configurations of libc++ that are tested by our build bots. Differential Revision: https://reviews.llvm.org/D81293 | 6 年前 | |
[cmake] Add hexagon-linux cmake cache files (#98712) These can be used to create a fully-bootstrapped toolchain to target hexagon {baremetal,linux} with scripts like the ones in https://github.com/quic/toolchain_for_hexagon | 1 年前 | |
[libc++] basic_ios<wchar_t> cannot store fill character WCHAR_MAX (#89305) libcxx std::basic_ios uses WEOF to indicate the fill value is uninitialized. On some platforms (e.g AIX and zOS in 64-bit mode) wchar_t is 4 bytes unsigned and wint_t is also 4 bytes which means WEOF cannot be distinguished from WCHAR_MAX by std::char_traits<wchar_t>::eq_int_type(), meaning this valid character value cannot be stored on affected platforms (as the implementation triggers reinitialization to widen(’ ’)). This patch introduces a new helper class _FillHelper uses a boolean variable to indicate whether the fill character has been initialized, which is used by default in libcxx ABI version 2. The patch does not affect ABI version 1 except for targets AIX in 32- and 64-bit and z/OS in 64-bit (so that the layout of the implementation is compatible with the current IBM system provided libc++) This is a continuation of Phabricator patch [D124555](https://reviews.llvm.org/D124555). This patch uses a modified version of the [approach](https://reviews.llvm.org/D124555#3566746) suggested by @ldionne . --------- Co-authored-by: Louis Dionne <ldionne.2@gmail.com> Co-authored-by: David Tenty <daltenty.dev@gmail.com> | 2 年前 | |
[libc++] basic_ios<wchar_t> cannot store fill character WCHAR_MAX (#89305) libcxx std::basic_ios uses WEOF to indicate the fill value is uninitialized. On some platforms (e.g AIX and zOS in 64-bit mode) wchar_t is 4 bytes unsigned and wint_t is also 4 bytes which means WEOF cannot be distinguished from WCHAR_MAX by std::char_traits<wchar_t>::eq_int_type(), meaning this valid character value cannot be stored on affected platforms (as the implementation triggers reinitialization to widen(’ ’)). This patch introduces a new helper class _FillHelper uses a boolean variable to indicate whether the fill character has been initialized, which is used by default in libcxx ABI version 2. The patch does not affect ABI version 1 except for targets AIX in 32- and 64-bit and z/OS in 64-bit (so that the layout of the implementation is compatible with the current IBM system provided libc++) This is a continuation of Phabricator patch [D124555](https://reviews.llvm.org/D124555). This patch uses a modified version of the [approach](https://reviews.llvm.org/D124555#3566746) suggested by @ldionne . --------- Co-authored-by: Louis Dionne <ldionne.2@gmail.com> Co-authored-by: David Tenty <daltenty.dev@gmail.com> | 2 年前 | |
[SystemZ][z/OS] Add ASCII and 32-bit variants for libc++. This patch enables libc++ build as shared library in all combinations of ASCII/EBCDIC and 32-bit/64-bit variants. In particular it introduces: # ASCII version of libc++ named as libc++_a.so # Script to rename DLL name inside the generated side deck # Various names for dataset members where DLL libraries and their side decks will reside # Add the following options: - LIBCXX_SHARED_OUTPUT_NAME - LIBCXX_ADDITIONAL_COMPILE_FLAGS - LIBCXX_ADDITIONAL_LIBRARIES - LIBCXXABI_ADDITIONAL_COMPILE_FLAGS - LIBCXXABI_ADDITIONAL_LIBRARIES **Background and rational of this patch** The linker on z/OS creates a list of exported symbols in a file called side deck. The list contains the symbol name as well as the name of the DLL which implements the symbol. The name of the DLL depends on what is specified in the -o command line option. If it points to a USS file, than the DLL name in the side deck will be the USS file name. If it points to a member of a dataset then the DLL name in the side deck is the member name. If CMake could deal with z/OS datasets we could use -o that points to a dataset member name, but this does not seem to work so we have to produce a USS file as the DLL and then copy the content of the produced side deck to a dataset as well as rename the USS file name in the side deck to a dataset member name that corresponds to that DLL. Reviewed By: muiez, SeanP, ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D118503 | 3 年前 | |
[SystemZ][z/OS] Add ASCII and 32-bit variants for libc++. This patch enables libc++ build as shared library in all combinations of ASCII/EBCDIC and 32-bit/64-bit variants. In particular it introduces: # ASCII version of libc++ named as libc++_a.so # Script to rename DLL name inside the generated side deck # Various names for dataset members where DLL libraries and their side decks will reside # Add the following options: - LIBCXX_SHARED_OUTPUT_NAME - LIBCXX_ADDITIONAL_COMPILE_FLAGS - LIBCXX_ADDITIONAL_LIBRARIES - LIBCXXABI_ADDITIONAL_COMPILE_FLAGS - LIBCXXABI_ADDITIONAL_LIBRARIES **Background and rational of this patch** The linker on z/OS creates a list of exported symbols in a file called side deck. The list contains the symbol name as well as the name of the DLL which implements the symbol. The name of the DLL depends on what is specified in the -o command line option. If it points to a USS file, than the DLL name in the side deck will be the USS file name. If it points to a member of a dataset then the DLL name in the side deck is the member name. If CMake could deal with z/OS datasets we could use -o that points to a dataset member name, but this does not seem to work so we have to produce a USS file as the DLL and then copy the content of the produced side deck to a dataset as well as rename the USS file name in the side deck to a dataset member name that corresponds to that DLL. Reviewed By: muiez, SeanP, ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D118503 | 3 年前 |
libc++ / libc++abi configuration caches
This directory contains CMake caches for the supported configurations of libc++. Some of the configurations are specific to a vendor, others are generic and not tied to any vendor.
While we won't explicitly work to break configurations not listed here, any configuration not listed here is not explicitly supported. If you use or ship libc++ under a configuration not listed here, you should work with the libc++ maintainers to make it into a supported configuration and add it here.
Similarly, adding any new configuration that's not already covered must be discussed with the libc++ maintainers as it entails a maintenance burden.