llvm: update to v19.1.0

[oltolm]

Fixes #22043.

[mati865]

Either disable tests via -DLLVM_INCLUDE_TESTS=OFF or install clang-tools-extra:

$ pacman -Qo /clang64/lib/libclangApplyReplacements.a
/clang64/lib/libclangApplyReplacements.a is owned by mingw-w64-clang-x86_64-clang-tools-extra 18.1.8-1

Since there is no check() there is no point in building test utils, so the first option is better.

[mati865]

Looks like openmp requires python to build since https://github.com/llvm/llvm-project/commit/88dae3d5d0230747f3cbabdde9ac5ae9e5dc3f8d

[oltolm]

Looks like openmp requires python to build since llvm/llvm-project@88dae3d

Thank you.

I removed flang from this PR because it depends on the new mlir version. Now CLANG64 fails because of mingw-w64-llvm-openmp. Maybe I should move it to another PR with flang.

  -- The Fortran compiler identification is unknown
  -- Detecting Fortran compiler ABI info
  CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
  Missing variable is:
  CMAKE_Fortran_PREPROCESS_SOURCE
  CMake Error at D:/M/msys64/clang64/share/cmake/Modules/CMakeDetermineCompilerABI.cmake:74 (try_compile):
    Failed to generate test project build system.
  Call Stack (most recent call first):
    D:/M/msys64/clang64/share/cmake/Modules/CMakeTestFortranCompiler.cmake:20 (CMAKE_DETERMINE_COMPILER_ABI)
    runtime/CMakeLists.txt:267 (enable_language)

[mmuetzel]

This is looking good so far. But the CLANG64 runner timed out. What you potentially could do is dropping mlir from this PR. Afaict, it is currently only required to build flang. Since you already dropped flang from here, you could drop mlir, too.

If that succeeds, you'd need to check if the build artifacts from here can be used to build the remaining LLVM packages. (You might need to check that locally.)

If you checked that all of them build correctly, you'd need to go ahead and check if the reverse dependencies already caught up to LLVM 19. That is probably especially the packages that depend on llvm-libs: https://packages.msys2.org/packages/mingw-w64-clang-x86_64-llvm-libs I.e., most likely arrow, spirv, and zig. If they build (or you found which patches would need to be cherry-picked to allow them to build with LLVM 19), we could start with merging this PR and follow up from there.

As long as we don't know that the update won't break at one of the steps described above, we probably shouldn't start merging this.

[mmuetzel]

For arrow, you might need to cherry-pick https://github.com/apache/arrow/pull/44233. For zig, maybe https://github.com/ziglang/zig/pull/21444. Edit: Maybe more complete: https://github.com/ziglang/zig/commit/c6ad4521c77372cb52adfb9a52b0854d830fed9c For SPIR-V, maybe update to version 19.1.0: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/releases/tag/v19.1.0

[oltolm]

I could update arrow and spirv-llvm-translator but not zig. The patches do not apply. I don't know what to do with zig. Update to git HEAD?

[ognevny]

I don't know what to do with zig

you don't have to rush with llvm update

[mmuetzel]

Oof. The list of packages that are affected by API/ABI changes in some shape or form is longer than I expected:

mingw-w64-zig
mingw-w64-qt-creator
mingw-w64-qt6-tools
mingw-w64-spirv-llvm-translator
mingw-w64-cvise
mingw-w64-flang
mingw-w64-mlir
mingw-w64-include-what-you-use
mingw-w64-arrow
mingw-w64-castxml
mingw-w64-qt6-static
mingw-w64-creduce
mingw-w64-mesa
mingw-w64-openshadinglanguage

Some of them are packages from the LLVM monorepo. So, the plan is to update them anyway. For most of the remaining packages, a simple rebuild might be enough. (Probably worth testing though.)

I could update arrow and spirv-llvm-translator but not zig. The patches do not apply. I don't know what to do with zig. Update to git HEAD?

If I'm reading the commit history for the zig package correctly, it was broken for several years and was only fixed in July. Maybe, @raedrizqie has an idea how to proceed with that package. (Maybe, break it again?)

[raedrizqie]

Maybe just dont rebuild zig after this update, and try rebuild zig on its next version update?

[oltolm]

I have updated most of the dependencies in my fork, but I'm not going to bother with mesa, include-what-you-use and qt.

[mmuetzel]

I'm not going to bother with mesa, include-what-you-use and qt.

Just to clarify: Does that mean you tried to rebuild them and they failed? Or you didn't try rebuilding them?

[oltolm]

I'm not going to bother with mesa, include-what-you-use and qt.

Just to clarify: Does that mean you tried to rebuild them and they failed? Or you didn't try rebuilding them?

I haven't tried rebuilding them.

[mmuetzel]

I haven't tried rebuilding them.

That's probably fine. At least Qt and mesa are usually pretty fast when updating to a new LLVM. I don't know about include-what-you-use. But we could probably try and fix a couple of potential issues "on the fly" should they arise.

The build queue is currently pretty busy with the rebuilds for Python 3.12. But after that is clear, we could probably start with this when you are ready for the follow-up PRs.

Do you have push access here (or should I or someone else merge when you are ready)?

[oltolm]

I'm just a regular contributor, I have no rights. Just merge whenever you want.

[DeepChirp]

Can we update directly to the latest 19.1.3 version?

[oltolm]

I think we should drop creduce. It has not been updated in a long time and there is an active fork cvise compatible with LLVM 19.

[MehdiChinoune]

I have rebuilt all packages except creduce and zig (waiting for qt6-static to finish). I am going to push the update after building qt6-static finishes successfully.

[MehdiChinoune]

update was pushed.