Update libcxx and libcxxabi from LLVM 20.1.8 to 21.1.8 #26058

aheejin · 2026-01-08T07:50:00Z

This updates libcxx and libcxxabi from 20.1.8 to LLVM 21.1.8:
https://github.com/llvm/llvm-project/releases/tag/llvmorg-21.1.8

This also updates LLVM's libc header directories that libcxx is dependent on:

llvm-libc/hdr
llvm-libc/include/llvm-libc-macros
llvm-libc/include/llvm-libc-types
llvm-libc/shared
llvm-libc/config

Additional changes:

Copy vendor/llvm/default_assertion_handler.in to __assertion_handler: 987b28c
Our previous __assertion_handler was copied from libcxx/vendor/llvm/default_assertion_handler.in. This updates our __assertion_handler to the new libcxx/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.
Build regal with -Wno-nonnull: a1fcbfc and 566c822
After [libc++] Diagnose when nullptrs are passed to string APIs llvm/llvm-project#122790, libcxx's std::basic_string's constructor is marked as _Nonnull. This suppresses the warnings.
Add module.modulemap to libcxx: 2a01e8b
libcxx used to have module.modulemap but it was changed to module.modulemap.in in [libc++] Make __config_site modular llvm/llvm-project#134699. This recreates module.modulemap from that module.modulemap.in. Without this other.test_cxx20_modules_std_headers fails.
Increase size expectations of test_malloc_size*: 09bc21e
This increase seems to be mainly due to the changes of implementation of std::num_put in libcxx/include/__locale_dir/num.h in [libc++] Granularize <locale> llvm/llvm-project#146650. This now calls other functions, namely __to_chars_integral and its helpers.

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.

This is an automatic change generated by tools/maint/rebaseline_tests.py. The following (12) test expectation files were updated by running the tests with `--rebaseline`: ``` codesize/test_codesize_cxx_ctors1.json: 149109 => 153388 [+4279 bytes / +2.87%] codesize/test_codesize_cxx_ctors2.json: 148513 => 152783 [+4270 bytes / +2.88%] codesize/test_codesize_cxx_except.json: 194578 => 199006 [+4428 bytes / +2.28%] codesize/test_codesize_cxx_except_wasm.json: 164093 => 168568 [+4475 bytes / +2.73%] codesize/test_codesize_cxx_except_wasm_legacy.json: 161751 => 166220 [+4469 bytes / +2.76%] codesize/test_codesize_cxx_lto.json: 125441 => 120672 [-4769 bytes / -3.80%] codesize/test_codesize_cxx_mangle.json: 258655 => 263309 [+4654 bytes / +1.80%] codesize/test_codesize_cxx_noexcept.json: 151526 => 155961 [+4435 bytes / +2.93%] codesize/test_codesize_cxx_wasmfs.json: 177088 => 181644 [+4556 bytes / +2.57%] codesize/test_codesize_files_wasmfs.json: 56055 => 56518 [+463 bytes / +0.83%] codesize/test_minimal_runtime_code_size_hello_embind.json: 15129 => 15201 [+72 bytes / +0.48%] codesize/test_minimal_runtime_code_size_hello_embind_val.json: 11858 => 11941 [+83 bytes / +0.70%] Average change: +1.58% (-3.80% - +2.93%) ```

sbc100

Can you mention in the PR title or description the version you are upgrading from (so it clear this is major update, not just a minor one).

As of LLVM 21 (llvm/llvm-project#122790), libcxx's `std::basic_string`'s constructor is marked as `_Nonnull`: https://github.com/llvm/llvm-project/blob/2078da43e25a4623cab2d0d60decddf709aaea28/libcxx/include/string#L1061 https://github.com/llvm/llvm-project/blob/2078da43e25a4623cab2d0d60decddf709aaea28/libcxx/include/__config#L1252 Comiling this with LLVM 21's libcxx errors out with: ```console ../emscripten/cache/ports/regal/regal-version_7/src/boost/boost/print/string_list.hpp:281:46: error: null passed to a callee that requires a non-null argument [-Werror,-Wnonnull] 281 | PushBack(*this).assign(string ? string : T(NULL)); | ^~~~ ../emscripten/cache/sysroot/include/unistd.h:33:14: note: expanded from macro 'NULL' 33 | #define NULL 0L ``` This suppresses the warnings.

These files use `exit`, which requires `#include <stdlib.h>`, but didn't have the include. These didn't error out because `libcxx/include/math.h` used to contain `#include <stdlib.h>` but not anymore. It was removed in llvm/llvm-project#139586.

This uses `exit`, which requires `#include <stdlib.h>`, but didn't have the include. This didn't error out because `libcxx/include/math.h` used to contain `#include <stdlib.h>` but not anymore. It was removed in llvm/llvm-project#139586.

libcxx used to have `module.modulemap` but it was changed to `module.modulemap.in` in llvm/llvm-project#134699. This recreates `module.modulemap` from that `module.modulemap.in`. Without this `other.test_cxx20_modules_std_headers` fails.

aheejin · 2026-01-11T18:07:17Z

Can you mention in the PR title or description the version you are upgrading from (so it clear this is major update, not just a minor one).

I updated the description.

This increase seems to be mainly due to the changes of implementaion of `std::num_put` in `system/lib/libcxx/include/__locale_dir/num.h`. This now calls functions, namely `__to_chars_integral` and its helpers.

sbc100 · 2026-01-14T00:57:31Z

I guess the only blocker for this change now is the codesize changes?

Could you rebase on top of the latest llvm 23 changes?

This is an automatic change generated by tools/maint/rebaseline_tests.py. The following (1) test expectation files were updated by running the tests with `--rebaseline`: ``` codesize/test_codesize_cxx_lto.json: 125435 => 120666 [-4769 bytes / -3.80%] Average change: -3.80% (-3.80% - -3.80%) ```

aheejin · 2026-01-14T01:15:07Z

I guess the only blocker for this change now is the codesize changes?

Could you rebase on top of the latest llvm 23 changes?

Done

sbc100 · 2026-01-14T01:26:42Z

Remaining issues:

Code size changes: Should we investigate more before accepting them?
llvm-libc changes: Do we actually want a policy change here? Could we instead so a update of llvm-libc to the main branch, which might make any change to llvm-libc here unnecessary?

Since this change is quite big I wonder if its worth splitting out the test/fetch changes and landing those first?

aheejin · 2026-01-14T02:10:44Z

Remaining issues:

Code size changes: Should we investigate more before accepting them?

I looked into them, and while there is no single reason behind the increase, the most influential thing is the one I described in test_malloc_size* increase commit (09bc21e), that a class in libcxx is refactored and now it pulls in more functions. There doesn't seem to be a preprocessor switch that we can turn it on or off (there is no 'off' anyway). It doesn't even account for all increases; I guess around half is just various other changes in the implementation.

llvm-libc changes: Do we actually want a policy change here? Could we instead so a update of llvm-libc to the main branch, which might make any change to llvm-libc here unnecessary?

This PR only updates several directories in llvm-libc that libcxx depend on, and the updated files are newer than the current code. I think we can update them to tot eventually, but I don't see any downside in landing this first.

Also, I'd suggest we discuss more on whether we actually need to follow tot. It's harder to maintain and extract our changes.

Since this change is quite big I wonder if its worth splitting out the test/fetch changes and landing those first?

#26107

sbc100 · 2026-01-14T23:42:15Z

@kripken @juj WDYT this libc++ update? It comes with some minor codesize regressions of a few of Kb which for small programs could be a couple of percent I think. This time around there doesn't seem to be any one culprit here, just the many changes to upstream from the last 6 months. I'm tempted to just land this as is, since I don't think we want to be in the business of carrying major downstream patches (or even having to understand the inner workings of libc++ itself). I also don't think we want to be lagging in our libc++ version.

aheejin · 2026-01-15T00:28:22Z

For test_codesize_cxx_noexcept, these are the list of functions with their sizes, sorted in decreasing order, respectively built with the main branch vs. this branch. As you can see, many things have changed, and it's hard to pick a single culprit.
main.funcs.sorted.txt
lib21.funcs.sorted.txt

kripken · 2026-01-15T00:55:30Z

I agree with you two, the regressions seem spread out and not worth investigating in detail (unfortunately).

This is an automatic change generated by tools/maint/rebaseline_tests.py. The following (1) test expectation files were updated by running the tests with `--rebaseline`: ``` codesize/test_codesize_cxx_lto.json: 125443 => 120674 [-4769 bytes / -3.80%] Average change: -3.80% (-3.80% - -3.80%) ```

aheejin · 2026-01-15T02:25:13Z

Thanks! Can anyone LGTM this?

juj · 2026-01-15T12:24:29Z

@kripken @juj WDYT this libc++ update? It comes with some minor codesize regressions of a few of Kb which for small programs could be a couple of percent I think. This time around there doesn't seem to be any one culprit here, just the many changes to upstream from the last 6 months. I'm tempted to just land this as is, since I don't think we want to be in the business of carrying major downstream patches (or even having to understand the inner workings of libc++ itself). I also don't think we want to be lagging in our libc++ version.

Thanks for the heads-up.

I agree the codesize regression is a bit annoying, but given that this is from a third-party library, it would be far more annoying to not go with the flow. So LGTM to land to keep things simple.

It is great to have the code size tests that we can see regressions like this, and their impact. Thanks @aheejin for also investigating in that direction.

Given that most of Emscripten system headers do not require/depend on libc++, the regression is not unconditional to all users. So if users are avoiding libc++, the issue does not occur. (The only exception here being wasmfs, sadly)

~~Anyhow, LGTM to land.~~ Actually, had two minor questions..

juj · 2026-01-15T12:25:48Z

tools/ports/regal.py

@@ -110,6 +110,9 @@ def create(final):
      '-Wno-unused-parameter',
      '-Wno-nontrivial-memaccess',
      '-fdelayed-template-parsing',
+      # src/boost/boost/print/string_list.hpp calls std::string(NULL), whose
+      # consturctor is declared _Nonnull
+      '-Wno-nonnull',


Do you know what happens in practice when calling std::string(NULL) in the new libc++? That won't cause an immediate crash?

(consturctor -> constructor)

Spec-wise, it's UB.
In practice, it depends on the hardening mode.

Hardening mode was added in LLVM 19, and it provides additional checks for UB. More you check you pay more in runtime performance. There are four modes:

emscripten/system/lib/libcxx/include/__config

Lines 48 to 68 in 6aa30fb

// The library provides the macro `_LIBCPP_HARDENING_MODE` which can be set to one of the following values:

//

// - `_LIBCPP_HARDENING_MODE_NONE`;

// - `_LIBCPP_HARDENING_MODE_FAST`;

// - `_LIBCPP_HARDENING_MODE_EXTENSIVE`;

// - `_LIBCPP_HARDENING_MODE_DEBUG`.

//

// These values have the following effects:

//

// - `_LIBCPP_HARDENING_MODE_NONE` -- sets the hardening mode to "none" which disables all runtime hardening checks;

//

// - `_LIBCPP_HARDENING_MODE_FAST` -- sets that hardening mode to "fast". The fast mode enables security-critical checks

// that can be done with relatively little runtime overhead in constant time;

//

// - `_LIBCPP_HARDENING_MODE_EXTENSIVE` -- sets the hardening mode to "extensive". The extensive mode is a superset of

// the fast mode that additionally enables checks that are relatively cheap and prevent common types of logic errors

// but are not necessarily security-critical;

//

// - `_LIBCPP_HARDENING_MODE_DEBUG` -- sets the hardening mode to "debug". The debug mode is a superset of the extensive

// mode and enables all checks available in the library, including internal assertions. Checks that are part of the

// debug mode can be very expensive and thus the debug mode is intended to be used for testing, not in production.

We disabled it when we updated to LLVM 19 not to pay runtime performance cost:

emscripten/system/lib/libcxx/include/__config_site

Lines 26 to 27 in 6aa30fb

// Hardening

#define _LIBCPP_HARDENING_MODE_DEFAULT _LIBCPP_HARDENING_MODE_NONE

std::basic_string has this when the input is null:

emscripten/system/lib/libcxx/include/string

Line 1083 in 6aa30fb

_LIBCPP_ASSERT_NON_NULL(__s != nullptr, "basic_string(const char*) detected nullptr");

But _LIBCPP_ASSERT_NON_NULL is enabled only when the hardening mode is _LIBCPP_HARDENING_MODE_EXTENSIVE or _LIBCPP_HARDENING_MODE_DEBUG. Because we currently use _LIBCPP_hardening_MODE_NONE, it does nothing:

emscripten/system/lib/libcxx/include/__assert

Line 104 in 6aa30fb

# define _LIBCPP_ASSERT_NON_NULL(expression, message) ((void)0)

So for us, it won't immediately crash and the program can malfunction.

It'd be better if we can avoid this. I considered emscripten-ports/regal#10, but @sbc100 suggested we probably would't want to maintain the port.

So this suppresses the warning. This at least doesn't make things worse, because that code was already there for years.

juj · 2026-01-15T12:26:28Z

test/test_other.py

-    'emmalloc_O2': (['-sMALLOC=emmalloc', '-O2'], 125000),
-    'dlmalloc_O2': (['-sMALLOC=dlmalloc', '-O2'], 132000),
-    'mimalloc_O2': (['-sMALLOC=mimalloc', '-O2'], 180000),
+    'emmalloc_O2': (['-sMALLOC=emmalloc', '-O2'], 130000),


Hmm, emmalloc does not utilize libc++ - do you know why this change in size?

sbc100 · 2026-01-15T18:45:26Z

LGTM once we figure out why the malloc benchmark changed.

sbc100

Oh wait, the answer is pretty obvious test_malloc_size uses hello_libcxx.cpp to measure codesize which includes libc++

sbc100 · 2026-01-15T20:21:44Z

Feel free to land this. Once we do we should probably cut a new release.

sbc100 · 2026-01-16T17:00:58Z

Can we land this now?

aheejin added 7 commits January 8, 2026 05:24

Update libcxxabi to LLVM 21.1.8

466d047

Update libcxx to LLVM 21.1.8

bd5a69b

Update llvm-libc headers for libcxx to LLVM 21.1.8

c48a705

Update ChangeLog and readmes

0709599

Merge branch 'main' into update_libcxx_libcxxabi_21

9335cdd

This comment was marked as duplicate.

Sign in to view

sbc100 reviewed Jan 8, 2026

View reviewed changes

aheejin added 6 commits January 11, 2026 01:56

Merge branch 'main' into update_libcxx_libcxxabi_21

885725e

Include <stdlib.h> in test_fetch_*.cpp files 2

6d321e2

This uses `exit`, which requires `#include <stdlib.h>`, but didn't have the include. This didn't error out because `libcxx/include/math.h` used to contain `#include <stdlib.h>` but not anymore. It was removed in llvm/llvm-project#139586.

Add module.modulemap to libcxx

2a01e8b

libcxx used to have `module.modulemap` but it was changed to `module.modulemap.in` in llvm/llvm-project#134699. This recreates `module.modulemap` from that `module.modulemap.in`. Without this `other.test_cxx20_modules_std_headers` fails.

Add comment on regal -Wno-nonnull change

566c822

sbc100 changed the title ~~Update libcxx and libcxxabi to LLVM 21.1.8~~ Update libcxx and libcxxabi from LLVM 20 to 21 Jan 11, 2026

aheejin mentioned this pull request Jan 11, 2026

Which revision of LLVM is our llvm-libc based on? #26035

Open

aheejin added 3 commits January 13, 2026 04:47

Merge branch 'main' into update_libcxx_libcxxabi_21

58bbc80

Increase size expectations of test_malloc_size*

09bc21e

This increase seems to be mainly due to the changes of implementaion of `std::num_put` in `system/lib/libcxx/include/__locale_dir/num.h`. This now calls functions, namely `__to_chars_integral` and its helpers.

Merge ChangeLog with compiler-rt

e34534e

aheejin changed the title ~~Update libcxx and libcxxabi from LLVM 20 to 21~~ Update libcxx and libcxxabi from LLVM 20.1.8 to 21.1.8 Jan 13, 2026

aheejin marked this pull request as ready for review January 13, 2026 06:58

aheejin added 6 commits January 13, 2026 21:04

Merge branch 'main' into update_libcxx_libcxxabi_21

ee69cd4

Fix ChangeLog PR number

38ac7a2

Merge branch 'main' into update_libcxx_libcxxabi_21

0467400

Merge branch 'main' into update_libcxx_libcxxabi_21

c70d9c1

ChangeeLog conflict fix

6cad1a0

Merge branch 'main' into update_libcxx_libcxxabi_21

ee65f7f

Merge branch 'main' into update_libcxx_libcxxabi_21

b219a4a

aheejin added 2 commits January 15, 2026 00:56

Merge branch 'main' into update_libcxx_libcxxabi_21

bff4451

juj reviewed Jan 15, 2026

View reviewed changes

sbc100 approved these changes Jan 15, 2026

View reviewed changes

aheejin added 2 commits January 15, 2026 21:57

Merge branch 'main' into update_libcxx_libcxxabi_21

0ddd758

consturctor -> constructor

2d188d3

aheejin merged commit 48ee51e into emscripten-core:main Jan 16, 2026
36 checks passed

aheejin deleted the update_libcxx_libcxxabi_21 branch January 16, 2026 21:08

google-yfyang mentioned this pull request Jan 22, 2026

Update llvm-libc to llvm 21.1.8 #26151

Open

	// The library provides the macro `_LIBCPP_HARDENING_MODE` which can be set to one of the following values:
	//
	// - `_LIBCPP_HARDENING_MODE_NONE`;
	// - `_LIBCPP_HARDENING_MODE_FAST`;
	// - `_LIBCPP_HARDENING_MODE_EXTENSIVE`;
	// - `_LIBCPP_HARDENING_MODE_DEBUG`.
	//
	// These values have the following effects:
	//
	// - `_LIBCPP_HARDENING_MODE_NONE` -- sets the hardening mode to "none" which disables all runtime hardening checks;
	//
	// - `_LIBCPP_HARDENING_MODE_FAST` -- sets that hardening mode to "fast". The fast mode enables security-critical checks
	// that can be done with relatively little runtime overhead in constant time;
	//
	// - `_LIBCPP_HARDENING_MODE_EXTENSIVE` -- sets the hardening mode to "extensive". The extensive mode is a superset of
	// the fast mode that additionally enables checks that are relatively cheap and prevent common types of logic errors
	// but are not necessarily security-critical;
	//
	// - `_LIBCPP_HARDENING_MODE_DEBUG` -- sets the hardening mode to "debug". The debug mode is a superset of the extensive
	// mode and enables all checks available in the library, including internal assertions. Checks that are part of the
	// debug mode can be very expensive and thus the debug mode is intended to be used for testing, not in production.

	// Hardening
	#define _LIBCPP_HARDENING_MODE_DEFAULT _LIBCPP_HARDENING_MODE_NONE

Update libcxx and libcxxabi from LLVM 20.1.8 to 21.1.8 #26058

Update libcxx and libcxxabi from LLVM 20.1.8 to 21.1.8 #26058

Uh oh!

Conversation

aheejin commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as duplicate.

Uh oh!

sbc100 left a comment

Choose a reason for hiding this comment

Uh oh!

aheejin commented Jan 11, 2026

Uh oh!

sbc100 commented Jan 14, 2026

Uh oh!

aheejin commented Jan 14, 2026

Uh oh!

sbc100 commented Jan 14, 2026

Uh oh!

aheejin commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sbc100 commented Jan 14, 2026

Uh oh!

aheejin commented Jan 15, 2026

Uh oh!

kripken commented Jan 15, 2026

Uh oh!

aheejin commented Jan 15, 2026

Uh oh!

juj commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

juj Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

aheejin Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

juj Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

sbc100 commented Jan 15, 2026

Uh oh!

sbc100 left a comment

Choose a reason for hiding this comment

Uh oh!

sbc100 commented Jan 15, 2026

Uh oh!

sbc100 commented Jan 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

aheejin commented Jan 8, 2026 •

edited

Loading

aheejin commented Jan 14, 2026 •

edited

Loading

juj commented Jan 15, 2026 •

edited

Loading

aheejin Jan 15, 2026 •

edited

Loading