Update libcxx and libcxxabi to LLVM 20.1.4 #24346
Open
+73,021
−21,887
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Our prevous `__assertion_handler` was copied from `libcxx/vendor/llvm/default_assertion_handler.in`. This updates out `__assertion_handler` to the new `libcxx/vendor/llvm/default_assertion_handler.in`. For what this file is, see the PR description of emscripten-core#22994, with which the file was added.
As I described in "Freezing C++ headers" above, C++03 headers were copied to `include/cxx03` to be "frozen". But by not defining `_LIBCPP_USE_FROZEN_CXX03_HEADERS` we can still use the main headers. This new `__cxx03` header directory is almost 10M and we are not using it in this update, this deletes it.
libcxx decides to almost all configuration macros to be defined. So before it tested whether a macro was defined/undefined, and now it assumes it is defined and tests whether its value is 1/0. Before llvm/llvm-project#112094 `_config_site.in` used to use `#cmakedefine`, which only defined variables when they were enabled, but now it uses `#cmakedefine01`, which always defines variables and assigns 1 or 0 depending on whether the feature is enabled. So this change adds `#define` to each variable that `_config_site.in` has an entry of. The value assigned is 1 if it was defined in our previous Emscripten environment and 0 if not.
Before, the code was like https://github.com/emscripten-core/emscripten/blob/dc1abd514b1bade135a01a4453a9ff6def0793b6/system/lib/libcxx/include/__locale_dir/locale_base_api.h#L12-L30 But now they are divided into two parts, one using the new API and the other using old. See "Locale API reimplementation" above. https://github.com/llvm/llvm-project/blob/ec28b8f9cc7f2ac187d8a617a6d08d5e56f9120e/libcxx/include/__locale_dir/locale_base_api.h#L116-L138 This adds Emscripten in the beginning of the "old" API list. (This has to be the beginning; see emscripten-core#23414)
This imports a part of libc headers into `system/lib/llvm-libc`. The imported directories are: - `libc/shared` - `libc/src/__support` - `libc/include/llvm-libc-macros` - `libc/include/llvm-libc-types` - `libc/hdr` See "sharing of headers between libc+ and libc" above for details.
LLVM 20 release contains a bug that it one of the headers in `libc/src/__support` directory includes a header from `libc/src/errno`, which is not one of the header directories that are meant to be included: https://github.com/llvm/llvm-project/blob/ec28b8f9cc7f2ac187d8a617a6d08d5e56f9120e/libc/src/__support/str_to_float.h#L34 I was told (llvm/llvm-project#91651 (comment)) this was a bug that was fixed in llvm/llvm-project#133999. Whether this fix will be backported to later version of LLVM 20 release is unclear. To avoid importing files from `libc/src`, this applies the fix here as well.
`std::uncaught_exception` has been deprecated in C++17, so it generates a warning (which we treat as an error). Replaced it with `std::uncaught_exceptions`, which returns the number of uncaught exceptions (but can still be used as a boolean in the test).
This rebaselines other.test_codesize_files_wasmfs other.test_codesize_cxx_except other.test_codesize_cxx_mangle These have `*.imports` or `*.funcs` so `rebaseline_tests.py` cannot handle them. So this rebaselines them manually.
This is an automatic change generated by tools/maint/rebaseline_tests.py. The following (9) test expectation files were updated by running the tests with `--rebaseline`: ``` code_size/embind_hello_wasm.json: 16727 => 16673 [-54 bytes / -0.32%] code_size/embind_val_wasm.json: 16377 => 16323 [-54 bytes / -0.33%] other/codesize/test_codesize_cxx_ctors1.size: 129217 => 129654 [+437 bytes / +0.34%] other/codesize/test_codesize_cxx_ctors2.size: 128610 => 129039 [+429 bytes / +0.33%] other/codesize/test_codesize_cxx_except_wasm.size: 144593 => 144770 [+177 bytes / +0.12%] other/codesize/test_codesize_cxx_except_wasm_legacy.size: 142168 => 142360 [+192 bytes / +0.14%] other/codesize/test_codesize_cxx_lto.size: 121938 => 121882 [-56 bytes / -0.05%] other/codesize/test_codesize_cxx_noexcept.size: 131780 => 132027 [+247 bytes / +0.19%] other/codesize/test_codesize_cxx_wasmfs.size: 169161 => 169897 [+736 bytes / +0.44%] Average change: +0.09% (-0.33% - +0.44%) ```
|
The only failing test is So I think this error is not related. |
|
Indeed |
sbc100
approved these changes
May 16, 2025
Will do that in a follow-up. |
sbc100
approved these changes
May 16, 2025
|
After this we still have the compiler-rt changes right? Do you think its worth holding off making a release until that is done? (I was hoping to make a release soon). |
|
I think maybe even for this PR it's better to wait for at least several days to see whether the waterfall is stable, because this is also a big change. How about doing the release now (or in a few days) and I land this (and compiler-rt) later? |
|
Yes, I actually think it might be a good to get a release out once I land #24288.. then we can land this after the release. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This updates libcxx and libcxxabi to LLVM 20.1.4:
https://github.com/llvm/llvm-project/releases/tag/llvmorg-20.1.4
Before going into each additional change of the PR, these are some noteworthy changes from this LLVM release:
Freezing C++03 headers
__cxx03/headers in C++03 mode llvm/llvm-project#109002This copies libc++ headers of the last LLVM 19 release into a separate directory (https://github.com/llvm/llvm-project/tree/main/libcxx/include/__cxx03) and redirects all C++03 workflow there. The motivation is not to fix C++03 related changes unless they are critical bugs, and simplifies the main headers. So the main headers are like
As you can see it looks like we can avoid opting into this by not defining
_LIBCPP_USE_FROZEN_CXX03_HEADERSat the moment. I think their eventual goal is to remove C++03 support from the main headers but it hasn't seem to have happened yet and I don't know what their timeline for that is.Adding that
__cxx03directory increases the header size by 10MB. We can get away not using them by not defining_LIBCPP_USE_FROZEN_CXX03_HEADERSin this release, so this update does not include that directory.Sharing of headers between libc++ and libc (Project Hand in Hand)
This tries to share some libc headers from libcxx. libcxx's source files can depend on headers from
libc/shared,libc/src/__support,libc/include/llvm-libc-macros, andlibc/include/llvm-libc-types. And it turns out libcxx can also depend onlibc/hdr, even though the directory is not in the diagram in the RFC.These headers can be only included from
libcxx/srcand notlibcxx/include, to prevent libcxx's API from changing. So these headers don't need to be copied intocache/.Locale API reimplementation
It doesn't seem to have an RFC, but the PRs are:
It looks this aims provide a new way to define locale API for each platform. Currently Apple, FreeBSD, MSVCRT, and Fuschia are using the new API and the others are still using the old one: https://github.com/llvm/llvm-project/blob/ec28b8f9cc7f2ac187d8a617a6d08d5e56f9120e/libcxx/include/__locale_dir/locale_base_api.h#L116-L138
For our purpose, adding
if defined(__EMSCRIPTEN__)entry to the list of "old" list seems to work for the moment, but we may need to move to the new way eventually later.Additional changes:
Copy
vendor/llvm/default_assertion_handler.into__assertion_handler: aa53648Our previous
__assertion_handlerwas copied fromlibcxx/vendor/llvm/default_assertion_handler.in. This updates our__assertion_handlerto the newlibcxx/vendor/llvm/default_assertion_handler.in. For what this file is, see the PR description of Update libcxx and libcxxabi to LLVM 19.1.4 #22994, with which the file was added.Remove
libcxx/include/__cxx03directory: d646f6bAs I described in "Freezing C++ headers" above, C++03 headers were copied to
include/cxx03to be "frozen". But by not defining_LIBCPP_USE_FROZEN_CXX03_HEADERSwe can still use the main headers. This new__cxx03header directory is almost 10M and we are not using it in this update, this deletes it.Define more variables in
__config_site: 9912236libcxx decides to almost all configuration macros to be defined. So before it tested whether a macro was defined/undefined, and now it assumes it is defined and tests whether its value is 1/0.
Before [libc++] Refactor the configuration macros to being always defined llvm/llvm-project#112094
_config_site.inused to use#cmakedefine, which only defined variables when they were enabled, but now it uses#cmakedefine01, which always defines variables and assigns 1 or 0 depending on whether the feature is enabled.So this change adds
#defineto each variable that_config_site.inhas an entry of. The value assigned is 1 if it was defined in our previous Emscripten environment and 0 if not.Fix Emscripten's locale: 2ae01b0
Before, the code was like
emscripten/system/lib/libcxx/include/__locale_dir/locale_base_api.h
Lines 12 to 30 in dc1abd5
But now they are divided into two parts, one using the new API and the other using old. See "Locale API reimplementation" above.
https://github.com/llvm/llvm-project/blob/ec28b8f9cc7f2ac187d8a617a6d08d5e56f9120e/libcxx/include/__locale_dir/locale_base_api.h#L116-L138
This adds Emscripten in the beginning of the "old" API list. (This has to be the beginning; see Fix compat between libc++ and emscripten's xlocale.h #23414)
Import libc headers used by libcxx: 12a4ee4, 12a4ee4 and 43c8ce4
This imports a part of libc headers into
system/lib/llvm-libc. The imported directories are:libc/sharedlibc/src/__supportlibc/include/llvm-libc-macroslibc/include/llvm-libc-typeslibc/hdrSee "sharing of headers between libc+ and libc" above for details.
This also applies [libc] Stop depending on .cpp files libcxx_shared_headers library. llvm/llvm-project#133999, which is a bugfix that has not be backported, which fixes the bug of including from a wrong directory.
std::uncaught_exception->std::uncaught_exceptions: 1bf4e78std::uncaught_exceptionhas been deprecated in C++17, so it generates a warning (which we treat as an error). Replaced it withstd::uncaught_exceptions, which returns the number of uncaught exceptions (but can still be used as a boolean in the test).