Update ROOT and Cling to LLVM22 by devajithvs · Pull Request #21658 · root-project/root

devajithvs · 2026-03-23T13:08:53Z

This Pull request:

This is a draft PR. Some tests are expected to fail.

We need LLVM22 support for the following before we can merge this:

CLAD
CppInterOp
AdaptiveCpp (Full LLVM22 support doesn't exist upstream yet, disable this now to not block the upgrade).

TODO:

Fix failing tests.
Squash and reorganize commits.
Separate PR for changes that can go independent of the upgrade.
Fix FIXME and temporary commits

Changes or fixes:

Checklist:

tested changes locally
updated the docs (if necessary)

This PR fixes #

github-actions · 2026-03-23T14:29:24Z

Test Results

21 files 21 suites 2d 4h 45m 1s ⏱️
3 844 tests 3 843 ✅ 0 💤 1 ❌
72 094 runs 72 092 ✅ 1 💤 1 ❌

For more details on these failures, see this check.

Results for commit 0836c20.

♻️ This comment has been updated with latest results.

ferdymercury · 2026-03-23T17:19:05Z

AdaptiveCpp - potentially

Related: AdaptiveCpp/AdaptiveCpp#1986

mcbarton · 2026-03-23T20:42:17Z

Here is the PR I have updating CppInterOp to llvm 22 compiler-research/CppInterOp#812 . It builds with llvm 22 (tested through the ci with upstream llvm 22 and clang-repl), but several tests currently fail. Unsure how the patch would fair with roots llvm 22 and cling.

- Update headers and enums - Use options library - llvm/llvm-project@f63d33d - Do not share ownership of HeaderSearchOptions - llvm/llvm-project@77148fc - Update function signatures for Sema::*InstantiationScope - llvm/llvm-project@c1468e9 - API Changes related to InfosShard - llvm/llvm-project@cd269fe - Use IdentifierLoc - llvm/llvm-project@d83b639 - Add isInjectedClassName - StringSet API update - Update function signatures - getDependentSizedArrayType - setObjectLinkingLayerCreator - llvm/llvm-project@b18e5b6 - memory manager factory - llvm/llvm-project@ea709c7 - llvm/llvm-project@cd58586 - API change: getAsmStringExpr - llvm/llvm-project@911b200 - API changes related to SFINAE - llvm/llvm-project@d2f75f2 - Replace getContext with WithContextDo - llvm/llvm-project@0bfa0bc

… removal This will fix gtest-tree-ntuple-ntuple-type-name, that was failing prior to this commit. We probably need to revisit this and find a better/generalized way to handle all similar cases. Fix for cppyy-test-pythonization

The Transform.C test was constructing a bare Transform::Config that did not populate m_toReplace, so the basic_string<char> to std::string substitution could not fire during partial desugaring, causing the test to produce "std::pair<const std::basic_string<char>, int>" instead of the expected "std::pair<const std::string, int>". Mirror what TNormalizedCtxImpl does: look up std::string, take its canonical type pointer as the key, and insert the typedef type as the replacement value in m_toReplace.

Prior to LLVM22, GetNormalizedName would strip Class keyword from nested template arguments as a side-effect of ElaboratedType desugaring. This was accidental erasure of user-written syntax. In LLVM22, ElaboratedType was removed and the keyword is stored directly on TagType. The normalization code no longer strips it, so the output now reflects what the user wrote:

The change in getFullyQualifiedType() in the commit llvm/llvm-project@af27466 added explicit desugaring of UsingType: ``` if (isa<UsingType>(QT.getTypePtr())) { return getFullyQualifiedType(QT.getSingleStepDesugaredType(Ctx), Ctx, WithGlobalNsPrefix); } ``` This has been there since LLVM14 and we could disentagle this from the upgrade. This causes `SG::sgkey_t` to be resolved to its underlying type `uint32_t` when GetFullTypeName() is called, rather than preserving the typedef alias name as before. For now, update the test expectation to reflect the new behavior or move this to a separate PR.

Unmark xfail for test14_templated_return_type

…ePaths CopyIncludePaths assumed that a framework entry always implies `Group==Angled` and called `report_fatal_error` for any other group. This changed after LLVM commit: llvm/llvm-project@515b4a4 Framework entries land in UserEntries with `IsFramework=true` and `Group=frontend::System` and cling fails on macos with "Invalid option set!" Fix by also allowing `Group=frontend::System` for framework entries. See compiler-research/CppInterOp#672 (comment)

LLVM22 introduced UnsubstitutedConstraintSatisfactionCache: llvm/llvm-project@e9972de This causes some stale results to persist across transactions For example, evaluating is_default_constructible_v<Inner<int>> for an incomplete Inner<int> caches the 'false' value here. Completing Inner<int> in the next transaction will see the cached 'false' instead of re-evaluating. There is a TODO in clang to make this a private member, so this solution is not ideal. This might not be the right fix, clang and clang-repl also fails for the below, maybe we should just update the test-case `roottest-root-meta-ROOT-7462-Test` to prevent this condition (gcc14 and above). Minimal reproducer: ``` template <typename T> struct X; // Forward declaration template <typename T> struct S { S() requires std::is_default_constructible_v<T> = default;}; bool b = std::is_default_constructible_v<S<X<int>>>; template <> struct X<int> {}; // Complete the definition of X<int> S<X<int>> s; // Fails without this patch ``` In ROOT: ``` { gInterpreter->Declare(R"( #include <type_traits> template <typename T> struct X; template <typename T> struct S { S() requires std::is_default_constructible_v<T> = default;}; )"); gInterpreter->Declare("bool b = std::is_default_constructible_v<S<X<int>>>;"); gInterpreter->Declare("template <> struct X<int> {};"); bool ok = gInterpreter->Declare("S<X<int>> s;"); printf("%s\n", ok ? "PASS" : "FAIL"); } ```

LLVM21 implements CWG2369 ("Ordering between constraints and substitution", llvm/llvm-project@e04e140 This moves constraint checking before full template argument substitution. Alias templates may be expanded eagerly during parameter type substitution, causing hard diagnostics to be emitted for substitution failures that are expected and handled by InstantiateTemplateWithDefaults(). Use SFINAETrap so that substitution failures are treated as silent failures, matching the previous behaviour. Fix the remaining failing `pyunittests` on macos: - pyunittests-bindings-distrdf-backend-distrdf-unit-backend-dist - pyunittests-bindings-distrdf-backend-distrdf-unit-backend-graph-caching - pyunittests-bindings-pyroot-cppyy-cppyy-test-cpp11features - pyunittests-bindings-pyroot-pythonizations-pyroot-roofit - pyunittests-io-io-rfile-py - pyunittests-tree-dataframe-dataframe-merge-results - pyunittests-tree-ntuple-ntuple-py-basics - pyunittests-tree-ntuple-ntuple-py-model

AdaptiveCpp does not support LLVM22 yet, there is a PR open, still need some work to get this building with static LLVM, adaptiveCpp is designed to be used as a clang plugin using libLLVM.so, for now, disable this so that this does not become a blocker for LLVM22 upgrade.

Clad support for LLVM22 hasn't been released yet. Temporarily turn this off for CI.

We need to keep siphash folder after the llvm commit: llvm/llvm-project@7f3afab9

We also need to update `CLANG_CMAKE_DIR` after the changes in: llvm/llvm-project@88b77073 We also need to add a patch to clad to get this building.

devajithvs · 2026-06-25T13:42:32Z

@smuzaffar, the CI looks good (except for a clad build issue on Windows, which should not affect CMSSW) for the LLVM 22 upgrade. Could you check this PR against CMSSW?

devajithvs · 2026-06-26T07:29:06Z

@vgvassilev, would you have an idea why clad build on windows is failing here?


cl : command line error D8021: invalid numeric argument '/Wno-macro-redefined' [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad-prefix\src\clad-build\lib\Differentiator\cladDifferentiator.vcxproj] [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad.vcxproj]
  cl : command line error D8021: invalid numeric argument '/Wno-macro-redefined' [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad-prefix\src\clad-build\tools\cladPlugin.vcxproj] [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad.vcxproj]
  C:\Program Files\Microsoft Visual Studio\18\Community\MSBuild\Microsoft\VC\v180\Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for 'C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-mkdir.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-download.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-update.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-patch.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-configure.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-build.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-install.rule;C:\ROOT-CI\build\CMakeFiles\cf0c9c103a9368f09347bf3068b16817\clad-complete.rule;C:\ROOT-CI\build\CMakeFiles\12f73b81bb94717129353e988fa63fe5\clad.rule;C:\ROOT-CI\src\interpreter\cling\tools\plugins\clad\CMakeLists.txt' exited with code 1. [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad.vcxproj]
      20 Warning(s)
      3 Error(s)

smuzaffar · 2026-06-27T07:33:35Z

@vgvassilev , just like cms-sw#232, cmssw tests also fail for this PR with error below. Looks like RPM packaging is not happy with cuda.pcm tmp lock symlink with absolute path to build directory ( this path will be invalue after the packaging). I guess after running echo '#include <cuda_runtime.h>' | <root-dir>/bin/root -b -n -l , root cling leave behind a tmp symlink pointing to build dir path. I think ideally root/rootcling should delete the tmp pcm lock .... right?

warning: absolute symlink: /opt/cmssw/el9_amd64_gcc13/lcg/root/6.41.1-25f2180ee204e9858052369b955f3f20/lib/cuda.pcm.lock -> /data/cmsbld/jenkins/workspace/ib-run-pr-tests/testBuildDir/tmp/BUILDROOT/25f2180ee204e9858052369b955f3f20/opt/cmssw/el9_amd64_gcc13/lcg/root/6.41.1-25f2180ee204e9858052369b955f3f20/lib/cuda.pcm.lock-71c15b9d
error: Symlink points to BuildRoot: /opt/cmssw/el9_amd64_gcc13/lcg/root/6.41.1-25f2180ee204e9858052369b955f3f20/lib/cuda.pcm.lock -> /data/cmsbld/jenkins/workspace/ib-run-pr-tests/testBuildDir/tmp/BUILDROOT/25f2180ee204e9858052369b955f3f20/opt/cmssw/el9_amd64_gcc13/lcg/root/6.41.1-25f2180ee204e9858052369b955f3f20/lib/cuda.pcm.lock-71c15b9d

hahnjo · 2026-06-29T06:54:08Z

@vgvassilev , just like cms-sw#232, cmssw tests also fail for this PR with error below. Looks like RPM packaging is not happy with cuda.pcm tmp lock symlink with absolute path to build directory ( this path will be invalue after the packaging). I guess after running echo '#include <cuda_runtime.h>' | <root-dir>/bin/root -b -n -l , root cling leave behind a tmp symlink pointing to build dir path. I think ideally root/rootcling should delete the tmp pcm lock .... right?

I'm not sure: Given this happens before the upgrade, with LLVM 20, and here, are we sure it's not related to how PRs are built and tested? Is there something different in PR builds compared to full IB builds? Can we maybe try an "empty" PR and see how that goes?

vgvassilev · 2026-06-29T08:41:18Z

@vgvassilev, would you have an idea why clad build on windows is failing here?


cl : command line error D8021: invalid numeric argument '/Wno-macro-redefined' [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad-prefix\src\clad-build\lib\Differentiator\cladDifferentiator.vcxproj] [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad.vcxproj]
  cl : command line error D8021: invalid numeric argument '/Wno-macro-redefined' [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad-prefix\src\clad-build\tools\cladPlugin.vcxproj] [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad.vcxproj]
  C:\Program Files\Microsoft Visual Studio\18\Community\MSBuild\Microsoft\VC\v180\Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for 'C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-mkdir.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-download.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-update.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-patch.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-configure.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-build.rule;C:\ROOT-CI\build\CMakeFiles\e27416e9837b8dc018ca268d6f8dd04a\clad-install.rule;C:\ROOT-CI\build\CMakeFiles\cf0c9c103a9368f09347bf3068b16817\clad-complete.rule;C:\ROOT-CI\build\CMakeFiles\12f73b81bb94717129353e988fa63fe5\clad.rule;C:\ROOT-CI\src\interpreter\cling\tools\plugins\clad\CMakeLists.txt' exited with code 1. [C:\ROOT-CI\build\interpreter\cling\tools\plugins\clad\clad.vcxproj]
      20 Warning(s)
      3 Error(s)

Is that still an issue?

smuzaffar · 2026-06-29T13:18:10Z

@vgvassilev , just like cms-sw#232, cmssw tests also fail for this PR with error below. Looks like RPM packaging is not happy with cuda.pcm tmp lock symlink with absolute path to build directory ( this path will be invalue after the packaging). I guess after running echo '#include <cuda_runtime.h>' | <root-dir>/bin/root -b -n -l , root cling leave behind a tmp symlink pointing to build dir path. I think ideally root/rootcling should delete the tmp pcm lock .... right?

I'm not sure: Given this happens before the upgrade, with LLVM 20, and here, are we sure it's not related to how PRs are built and tested? Is there something different in PR builds compared to full IB builds? Can we maybe try an "empty" PR and see how that goes?

I have started building root (for cmssw) without any change here and it build fine. RPM packaging did not complain about the lock file. I think something is merged in root master branch after 6bf5355cc45 which created a lock file without deleting it and then RPM packaging complains about it

ferdymercury · 2026-06-29T13:23:38Z

something is merged in root master branch

Maybe 05b3123 ?

hahnjo · 2026-06-29T13:32:09Z

something is merged in root master branch

Maybe 05b3123 ?

Yes, this would also be my guess. Shall we move the discussion to cms-sw/cmsdist#10684 since this is not related to the LLVM upgrade?

devajithvs self-assigned this Mar 23, 2026

devajithvs added skip code analysis Skip the code analysis CI steps for this PR, including verifying clang-formatting and running Ruff. clean build Ask CI to do non-incremental build on PR labels Mar 23, 2026

devajithvs force-pushed the ROOT-llvm22 branch 2 times, most recently from 255c7e6 to cfd796b Compare March 23, 2026 13:19

devajithvs force-pushed the ROOT-llvm22 branch from cfd796b to dbf8c51 Compare March 23, 2026 17:04

devajithvs force-pushed the ROOT-llvm22 branch 2 times, most recently from 7738727 to d68c1c7 Compare March 24, 2026 09:28

devajithvs force-pushed the ROOT-llvm22 branch 2 times, most recently from 7640bdc to 8920b0a Compare March 31, 2026 14:12

devajithvs force-pushed the ROOT-llvm22 branch 2 times, most recently from 88b794b to 6284651 Compare April 20, 2026 12:45

devajithvs force-pushed the ROOT-llvm22 branch 2 times, most recently from 8d87ccb to 1aa5aae Compare May 4, 2026 07:44

devajithvs force-pushed the ROOT-llvm22 branch from 9561d89 to 0401759 Compare May 13, 2026 08:13

devajithvs force-pushed the ROOT-llvm22 branch from 3e8a41d to 271d3a7 Compare May 21, 2026 09:23

devajithvs force-pushed the ROOT-llvm22 branch 3 times, most recently from 69156a4 to 8f2e30f Compare June 15, 2026 16:29

devajithvs mentioned this pull request Jun 16, 2026

[cling] Pre LLVM22 changes that can go before the actual upgrade #22616

Merged

devajithvs force-pushed the ROOT-llvm22 branch 5 times, most recently from 723d4ab to 0ec80c2 Compare June 23, 2026 15:40

devajithvs added 2 commits June 24, 2026 10:55

Import ROOT-llvm22

25559c6

devajithvs added 13 commits June 24, 2026 10:55

[cling][test] Update output print types

eadd520

[roottest] Update reference files after LLVM22

2b2acbe

[cppyy] Unmark xfail, this test now passes with LLVM22

8e93beb

Unmark xfail for test14_templated_return_type

[cling] Enable SuppressTagKeywordInAnonNames by default

0f2a63d

[clad] Disable clad temporarily

56e98e5

Clad support for LLVM22 hasn't been released yet. Temporarily turn this off for CI.

devajithvs force-pushed the ROOT-llvm22 branch from 0ec80c2 to c7b7cf3 Compare June 24, 2026 08:57

[CI][llvm-project] Only compare what is already there in third-party

45543a0

We need to keep siphash folder after the llvm commit: llvm/llvm-project@7f3afab9

devajithvs force-pushed the ROOT-llvm22 branch from c7b7cf3 to 45543a0 Compare June 24, 2026 11:55

[testing][temp] Re-enable clad for testing

0836c20

We also need to update `CLANG_CMAKE_DIR` after the changes in: llvm/llvm-project@88b77073 We also need to add a patch to clad to get this building.

This was referenced Jun 25, 2026

[ci] Add LLVM 22 ASan matrix row. vgvassilev/clad#1831

Merged

Skip backend pass registration when built as static library vgvassilev/clad#1854

Merged

smuzaffar mentioned this pull request Jun 26, 2026

Root llvm22 cms-sw/root#233

Open

smuzaffar mentioned this pull request Jun 27, 2026

[WIP][Cling] Refactor CIFactory and add incremental action support #21903

Draft

2 tasks

hahnjo mentioned this pull request Jun 29, 2026

[ROOT6]Updated root to tip of branch master cms-sw/cmsdist#10684

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Update ROOT and Cling to LLVM22#21658

Update ROOT and Cling to LLVM22#21658
devajithvs wants to merge 30 commits into
root-project:masterfrom
devajithvs:ROOT-llvm22

devajithvs commented Mar 23, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Mar 23, 2026 •

edited

Loading

Uh oh!

ferdymercury commented Mar 23, 2026

Uh oh!

mcbarton commented Mar 23, 2026

Uh oh!

devajithvs commented Jun 25, 2026

Uh oh!

devajithvs commented Jun 26, 2026

Uh oh!

smuzaffar commented Jun 27, 2026

Uh oh!

hahnjo commented Jun 29, 2026

Uh oh!

vgvassilev commented Jun 29, 2026

Uh oh!

smuzaffar commented Jun 29, 2026 •

edited

Loading

Uh oh!

ferdymercury commented Jun 29, 2026

Uh oh!

hahnjo commented Jun 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Conversation

devajithvs commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

This Pull request:

Changes or fixes:

Checklist:

Uh oh!

github-actions Bot commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

ferdymercury commented Mar 23, 2026

Uh oh!

mcbarton commented Mar 23, 2026

Uh oh!

devajithvs commented Jun 25, 2026

Uh oh!

devajithvs commented Jun 26, 2026

Uh oh!

smuzaffar commented Jun 27, 2026

Uh oh!

hahnjo commented Jun 29, 2026

Uh oh!

vgvassilev commented Jun 29, 2026

Uh oh!

smuzaffar commented Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ferdymercury commented Jun 29, 2026

Uh oh!

hahnjo commented Jun 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

devajithvs commented Mar 23, 2026 •

edited

Loading

github-actions Bot commented Mar 23, 2026 •

edited

Loading

smuzaffar commented Jun 29, 2026 •

edited

Loading