Update ROOT and Cling to LLVM18 #15696
Open
+686,904
−336,622
Conversation
This file contains 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
Test Results 13 files 13 suites 3d 7h 50m 50s ⏱️ Results for commit 2443702. ♻️ This comment has been updated with latest results. |
|
I know this is totally not relevant for you, but I am still wondering: does this allow me to use system clang or are there still downstream patches required? |
Hi Stephan, no we still require downstream patches. Their number gets reduced on every upgrade, you can track the status for LLVM 18 here: https://github.com/root-project/llvm-project/commits/ROOT-llvm18. More importantly, and not yet reflected in |
|
Thanks for the update! |
|
Here is the stack trace on Windows: |
|
FWIW the current state compiles fine on RISC-V and is at least able to run |
devajithvs
force-pushed
the
dev.llvm18
branch
4 times, most recently
from
81d5c1b
to
d79963e
Compare
|
@smuzaffar, @devajithvs and @hahnjo have everything working reasonably with the llvm18 upgrade. Can you check this PR against cmssw? |
@iarspider, could you give us a hand? |
I allow myself to add @aandvalenzuela to perhaps get some help. |
- Rename `CharacterLiteral` enum to `CharacterLiteralKind`
- Rename `CGFT_{}` enums to `CodeGenFileType::{}`
- Rename `ETK_{}` enums to `ElaboratedTypeKeyword::{}`
- Rename `TTK_{}` enums to `TagTypeKind::{}`
- Use `ArraySizeModifier` and `StringLiteralKind`
- Use `LinkageSpecLanguageIDs`
- Rename `llvm::CodeGenOpt::Level` to `llvm::CodeGenOptLevel`
Adapt to the change introduced in https://reviews.llvm.org/D142347
We have to get the FAM via the MAM otherwise it won't invalidate function analyses in FAM See: https://reviews.llvm.org/D146160
- Include `EnterExpressionEvaluationContext.h` This was moved to its own header in: llvm/llvm-project@6d68805 - Include `StringExtras.h` This is now needed due to: llvm/llvm-project@3ff3af3
In LLVM 18 with incremental extensions enabled, the Preprocessor will never report tok::eof, but tok::annot_repl_input_end instead.
Prevents failures such as:
```
Processing roottest/root/meta/runnamespace.C...
Error in cling::MetaProcessor: cannot read from binary input:
'runnamespace.C'
```
This is needed for macros that start with `{` after the rebase
C++20 builds were failing due to the commit: llvm-project/commit/574ee1c02ef73b66c5957cf93888234b0471695f with an error `imported non C++20 importable modules`
This makes them run after the <Platform> library: It provides the __cxa_atexit function, which must not be found in the process.
LLVM now defines multiple Dylibs, and __cxa_atexit is provided in the <Platform> library.
We started seeing an assertion failure in ~FinalizedAlloc after commit d2479f4. Likely changed the destruction order that caused the assertion to trigger.
This fixes the Cling test Driver/E.C.
This applies the upstream changes in commit llvm/llvm-project@9992b38 to a copy of the modulemap from MacOSX14.2.sdk.
This fixes the failing python enum tests like: - `roottest-python-cpp-cpp` - `roottest-python-cmdLineUtils-ROOT_8197` Also remove `R__BYTESWAP` which should not be needed anymore. The leak was fixed with: llvm/llvm-project#78311 This caused our tests to fail as they relied on the previous behavior.
devajithvs
requested review from
bellenot,
vgvassilev,
dpiparo and
pcanal
as code owners
|
ROOT failed to build for aarch64, the build error is See https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-b2e919/41190/externals/root/6.33.01-1689b1f60f821828a7e2948d6cf5f908/log for detail root build log |
|
For x86_64, this change passed all cmssw CI tests |
Does both have the same version of gcc? Does one have |
|
@vgvassilev , gcc version is same (note that we use our own gcc and not from system). Both archs has [a]
[b] |
Upstream LLVM now unconditionally uses indirect / PC relative personality encodings since commit llvm/llvm-project@ca65969 This leads to references of DW.ref.__gxx_personality_v0 that cannot be resolved with RuntimeDyld, that we are still using for the moment. As a fix, auto-claim symbols as we are doing for PPC, see upstream commit: llvm/llvm-project@72ea1a7
|
@smuzaffar, can you rerun testing of this PR? |
|
@vgvassilev , @aandvalenzuela has already started the tests for aarch64 and looks like latest change has fixed the root build (tests are now building cmssw) |
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 Pull request:
Rebase
A few relevant LLVM commits that were referenced for the rebase:
Notes
TO DISCUSS/PROPERLY FIX
gtest-roofit-histfactory-test-testHistFactory.ClingMMapper#16314tutorial-hist-cumulativewhen JITLink is turned on. This works for now, but will need to investigate further on why resource trackers were not destructed in the right order.Changes or fixes:
Checklist:
This PR fixes #