You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By leaving compiler-rt on older versions, we risk breakage like with fcoverage. So if we want to support those features, it seems we don't have a choice but to update compiler-rt to tip of tree constantly.
Since basically forever we have been shipping tip-of-tree clang/llvm with stable/pinned version of the llvm libraries (libc++, libc++abi, compiler-rt).
However it seems that using an out-of-sync compiler-rt like this was probably never really a supported thing to do. See llvm/llvm-project#190708 (comment).
So going forward I suppose we need to keep compiler-rt more up-to-date than we have been. We maybe don't need to update it daily like we do with llvm but at least periodically, and not just every time there is a stable llvm release.
@dschuff does this make sense to you? How have we gotten away with this behaviour for so long I wonder?
We are due for LLVM 22 library updates anyway. Would updating to 22, meaning close enough version from ToT, work? Or does this have to be ToT? I don't really know what "raw profile format version" is, but given that its number is only 11, it seems this doesn't change very often.
Here we would be pointing the git submodule at the compiler-rt narrow clone that is maintained in chromium.googlesource.com. This is effectively a slice of the llvm-project repo.
If we don't want to use git submodule we could use git subtree and point that at the compiler-rt subdirectory of llvm-project. That way the commit shas would match upstream llvm commit shas. For an example of how git subtree works see WebAssembly/wasi-libc#797. They seem pretty clever.
@sbc100 is OpenMP also something to consider with this as well.
Aligning Emscripten holistically with LLVM might make sense to ensure the entire toolchain and runtime target a specific LLVM commit. That could extend as far as libc++, libc++abi, and any other components coming out of llvm-project.
It also seems like a simpler story than tracking the version of each component and updating them independently. Otherwise, the compatibility matrix becomes difficult to reason about and feels somewhat opaque.
It's not quite as bad as that. Currently there isn't a version for each component, there's basically "the compiler" (clang/LLVM/lld; these are continuously updated to tip of tree) and "the runtimes" (libc++, libc++abi compiler-rt; these are updated on major releases). If we had direct emscripten support for OpenMP, we'd make it match the other runtimes.
The historical reason is that we were adding features to clang/LLVM so rapidly that we didn't want to wait 6 months to get them to our users (and we were willing to pay more continuous integration and testing costs), whereas this was less true for the runtimes.
Activity
sbc100 commentedon Jun 30, 2026
Since basically forever we have been shipping tip-of-tree clang/llvm with stable/pinned version of the llvm libraries (libc++, libc++abi, compiler-rt).
However it seems that using an out-of-sync compiler-rt like this was probably never really a supported thing to do. See llvm/llvm-project#190708 (comment).
So going forward I suppose we need to keep compiler-rt more up-to-date than we have been. We maybe don't need to update it daily like we do with llvm but at least periodically, and not just every time there is a stable llvm release.
@dschuff does this make sense to you? How have we gotten away with this behaviour for so long I wonder?
aheejin commentedon Jul 1, 2026
We are due for LLVM 22 library updates anyway. Would updating to 22, meaning close enough version from ToT, work? Or does this have to be ToT? I don't really know what "raw profile format version" is, but given that its number is only 11, it seems this doesn't change very often.
sbc100 commentedon Jul 1, 2026
The change in question just landed 2 days ago so I guess not? I guess the 22 branch was cut a while back?
sbc100 commentedon Jul 1, 2026
How about this plan:
Here we would be pointing the git submodule at the compiler-rt narrow clone that is maintained in chromium.googlesource.com. This is effectively a slice of the llvm-project repo.
If we don't want to use
git submodulewe could usegit subtreeand point that at the compiler-rt subdirectory of llvm-project. That way the commit shas would match upstream llvm commit shas. For an example of howgit subtreeworks see WebAssembly/wasi-libc#797. They seem pretty clever.sbc100 commentedon Jul 1, 2026
This way each time we pull in new llvm commits we can run
git submodule updateorgit subtree update.I guess that alternative is that we just improve / update the existing
system/lib/update_compiler_rt.pyso its easy/qucik to run.Update compiler-rt from LLVM 21.1.8 to 22.1.8 (#27245)
Temporarily disable -fcoverage-mapping test
Temporarily disable -fcoverage-mapping test (#27261)
arsnyder16 commentedon Jul 29, 2026
@sbc100 is OpenMP also something to consider with this as well.
Aligning Emscripten holistically with LLVM might make sense to ensure the entire toolchain and runtime target a specific LLVM commit. That could extend as far as libc++, libc++abi, and any other components coming out of llvm-project.
It also seems like a simpler story than tracking the version of each component and updating them independently. Otherwise, the compatibility matrix becomes difficult to reason about and feels somewhat opaque.
dschuff commentedon Aug 11, 2026
It's not quite as bad as that. Currently there isn't a version for each component, there's basically "the compiler" (clang/LLVM/lld; these are continuously updated to tip of tree) and "the runtimes" (libc++, libc++abi compiler-rt; these are updated on major releases). If we had direct emscripten support for OpenMP, we'd make it match the other runtimes.
The historical reason is that we were adding features to clang/LLVM so rapidly that we didn't want to wait 6 months to get them to our users (and we were willing to pay more continuous integration and testing costs), whereas this was less true for the runtimes.