Root llvm22#233
Conversation
|
test parameters:
|
|
A new Pull Request was created by @smuzaffar for branch cms/master/6bf5355cc45. @akritkbehera, @cmsbuild, @iarspider, @raoatifshad, @smuzaffar can you please review it and eventually sign? Thanks. |
|
cms-bot internal usage |
|
please test |
|
-1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-373920/54303/summary.html Failed External BuildI found compilation error when building: + echo 'test $?PY3_NUMPY_ROOT != 0 || source /data/cmsbld/jenkins/workspace/ib-run-pr-tests/testBuildDir/el9_amd64_gcc13/external/py3-numpy/1.26.4-6c7401133d71aa0fdd19f4799dadfbdf/etc/profile.d/init.csh'
+ echo fi
+ touch /data/cmsbld/jenkins/workspace/ib-run-pr-tests/testBuildDir/tmp/BUILDROOT/25f2180ee204e9858052369b955f3f20/opt/cmssw/el9_amd64_gcc13/lcg/root/6.41.1-25f2180ee204e9858052369b955f3f20/etc/profile.d/.autodependencies
Processing files: lcg+root+6.41.1-25f2180ee204e9858052369b955f3f20-1-1.x86_64
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
RPM build warnings:
Macro expanded in comment on line 497: %{pkginstroot}/lib
Macro expanded in comment on line 498: %{pkginstroot}
|
|
@smuzaffar Could you restart the test here with the updated branch? |
|
please test |
|
Pull request #233 was updated. |
|
Oops, sorry, my bad. Clad wasn't enabled in the PR. |
|
please test |
I just updated the clad tag for build. The tag in the previous build seems not to be up to date with v2.4 (needed for LLVM22). |
|
looks like with over 8000+ files changed , github api takes ages to update the Pull requests content. e.g. i.e. |
…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.
|
Pull request #233 was updated. |
We need to keep siphash folder after the llvm commit: llvm/llvm-project@7f3afab9
We also need to update after the changes in: llvm/llvm-project@88b77073
Backport upstream patch that fixes windows builds for clad, remove this in the next clad release
|
Pull request #233 was updated. |
Hi @smuzaffar, Can we verify that this is a failure related to the upgrade and not a pre-existing one? |
|
please test with cms-sw/cmssw#51432 for CMSSW_20_1_ROOT6_X |
|
@devajithvs , the failure |
|
please test with cms-sw/cmssw#51432 for CMSSW_20_1_ROOT6_X/el9_aarch64_gcc13 |
|
-1 Failed Tests: UnitTests The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic:
You can see more details here: Failed Unit TestsI found 1 errors in the following unit tests: ---> test BUFU_TEST had ERRORS Comparison SummarySummary:
|
|
cmssw tests results look good |
`getName()` can return a temporary std::string, so wrapping it in a StringRef left builtinNames holding dangling pointers. Copy the name into an owning std::string before storing it.
|
Pull request #233 was updated. |
CMSSW tests for root-project#21658