Bump LLVM to v21#59950
Conversation
|
Oh, cool, with the changes in #59946 temporarily incorporated here, for the platforms where compilation is successful (macos and freebsd) tests are already passing, that's encouraging. |
|
The compile error on linux seems to be a Werror for uninitialized variable in LLVM. It could easily be a false positive since it's in the part of the code where LLVM does it's trick with memory layout of objects... |
|
I think was fixed by llvm/llvm-project#177168, so we'll have to backport that PR to our fork (we want to build a newer patch version with other patches anyway) |
|
Windows build fails with I'll need help for that one. |
|
32-bit Windows somehow builds successfully, but then there's an interesting test failure Lines 664 to 669 in 3360c8c is that an ABI problem with Int128 on 32-bit systems? |
|
@xal-0 |
|
After Sam's fix to the 64-bit Windows build, its tests are successful 🥳 Ok, I guess now it's time to start a new rebuild of LLVM in Yggdrasil |
https://buildkite.com/julialang/julia-master/builds/55880#019d1a76-6b59-47af-badc-653ea1406ce2/L1440 |
|
We're still getting despite backporting llvm/llvm-project#177168, which puzzles me quite a bit. But also, I can't reproduce the warning/error with GCC 15. Edit: I can't reproduce the error with |
|
I'm temporarily (?) disabling the maybe uninitialized warning for the sake of moving forward because I don't know what to do with it (I can't even reproduce it with gcc from 9 to 15). All 64-bit platforms are looking good, both 32-bit platforms are sad about ccalls involving Int128 (incorrect result on windows, segfault in Linux). Analyzegc needs adapting to new clang API |
|
My pattern-matching-powered fix to the analyzegc build failure seems to have worked in the sense that now there are actual errors reported by the analysis: I'll let someone else have fun fixing them 🙃 Edit: my friendly assistant proposed the following patch diff --git a/src/Makefile b/src/Makefile
index 2f12ff8d80..11c5df6634 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -642,6 +642,8 @@ SA_EXCEPTIONS-jloptions.c := -Xanalyzer -analyzer-config -Xana
# clang doesn't understand that e->vars has the same value in save_env (NULL) and restore_env (assumed non-NULL)
SA_EXCEPTIONS-subtype.c := -Xanalyzer -analyzer-config -Xanalyzer silence-checkers="core.uninitialized.Assign;core.UndefinedBinaryOperatorResult"
SA_EXCEPTIONS-codegen.c := -Xanalyzer -analyzer-config -Xanalyzer silence-checkers="core"
+SA_EXCEPTIONS-gc-stock.c := -Xanalyzer -analyzer-config -Xanalyzer silence-checkers="core.FixedAddressDereference"
+SA_EXCEPTIONS-aotcompile.cpp := -Xanalyzer -analyzer-config -Xanalyzer silence-checkers="core.FixedAddressDereference"
# these need to be annotated (and possibly fixed)
SKIP_GC_CHECK := codegen.cpp rtutils.c
diff --git a/src/aotcompile.cpp b/src/aotcompile.cpp
index 1fbfd459fc..96220989fa 100644
--- a/src/aotcompile.cpp
+++ b/src/aotcompile.cpp
@@ -341,7 +341,10 @@ public:
jl_value_t *rval = jl_idset_get(list, keyset, val);
if (rval == NULL) {
ssize_t idx;
+ JL_GC_PROMISE_ROOTED(list);
list = jl_idset_put_key(list, val, &idx);
+ JL_GC_PROMISE_ROOTED(list);
+ JL_GC_PROMISE_ROOTED(keyset);
keyset = jl_idset_put_idx(list, keyset, idx);
}
}but I can't really judge it, so I'm not even trying to push these changes. |
|
All tests green, yay! Now only analyzegc is unhappy. |
|
@nanosoldier |
|
@maleadt What's up with nanosoldier? |
|
Down until further notice. |
|
@nanosoldier |
|
The package evaluation job you requested has completed - possible new issues were detected. Report summary❗ Packages that crashed5 packages crashed only on the current version.
458 packages crashed on the previous version too. ✖ Packages that failed83 packages failed only on the current version.
3904 packages failed on the previous version too. ✔ Packages that passed tests7 packages passed tests only on the current version.
5797 packages passed tests on the previous version too. ➖ Packages that were skipped altogether1409 packages were skipped on the previous version too. |
|
Of the 83 failing packages, I think
are just packages depending on LLVM.jl which doesn't support LLVM 21 yet? |
|
Notably if you increase the size the regression goes away, so I'm not super worried. |
|
@giordano can we put a geomean on those graphs? Currenlty it's hard to get a "are the changes overall good or bad" |
|
https://tealquaternion.camdvr.org/compare.html?start=dd0802b7462871a7d454af069fa0677c20d2edb0&end=0f2031fd150d453d8e86990e500f26c78c43adfa&stat=min-wall-time shows an overall mean (and also mean and ranges for regressions and improvements, separately), although I suggested @Zentrik showing the median rather than (or in addition to) the mean. The page also gives a "significance factor" to the outliers. |
|
LLVM.jl v9.5.0 supports LLVM 21, so PkgEval should be happier. |
|
@nanosoldier |
|
https://buildkite.com/julialang/julia-master/builds/56699#019db6e8-5381-4dc5-a597-1b52a270a056/L2218 |
|
The package evaluation job you requested has completed - possible new issues were detected. Report summary❗ Packages that crashed3 packages crashed only on the current version.
246 packages crashed on the previous version too. ✖ Packages that failed21 packages failed only on the current version.
1179 packages failed on the previous version too. ✔ Packages that passed tests8 packages passed tests only on the current version.
5830 packages passed tests on the previous version too. ~ Packages that at least loaded3539 packages successfully loaded on the previous version too. ➖ Packages that were skipped altogether4 packages were skipped only on the current version.
902 packages were skipped on the previous version too. |
|
Summary:
Apart from possibly SciBmad (and not sure it's due to this PR), the other errors are mainly timeouts and some LLVM-related JLLs not working (probably the packages need to allow the LLVM v21 builds). This is looking pretty good, but analyzegc needs to be fixed still. |
Clang.jl also uses Clang_unified_jll, which just needs to be rebuilt for LLVM 21.
This breaks because we currently rely on version bounds to select an appropriate version of LLVM_jll.jl, which obviously doesn't work when a single Julia release covers multiple LLVM versions. It probably warrants a LLVM_unified_jll just like Clang_unified_jll (even though these are botches). EDIT: both fixed. |
https://tealquaternion.camdvr.org/compare.html?start=dd0802b7462871a7d454af069fa0677c20d2edb0&end=0f2031fd150d453d8e86990e500f26c78c43adfa&stat=min-wall-time now shows geometric mean and median for all categories (regressions, improvements, all), and they both point to an overall slight improvement:
Thanks @Zentrik for implementing it! |
…EPOINT region JITDebugInfoRegistry::registerJITObject is annotated JL_NOTSAFEPOINT but called jl_as_global_root, which acquires global_roots_lock and may safepoint. Move the promotion into the jl_register_jit_object wrapper, iterating Info.ci_funcs directly so the JL_NOTSAFEPOINT body no longer needs to touch the global roots table. This pull request was written with the assistance of generative AI (Claude Opus 4.7). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
All green! Should do/test anything else here (benchmark/pkgeval again?)? |
|
I think this is good to merge |
|
Was the non-squash merge intentional here? |
|
no. |
JuliaLang#60339 was auto-closed when JuliaLang#59950 merged and can't be reopened. Co-authored-by: Claude <noreply@anthropic.com>

I won't be able to work on this besides for rebasing the PR and other small edits, I'm opening this PR to keep the ball rolling, but everyone is more than welcome to take it over.
This needs #59946 to start with.