[OpenMP] Remove LLVM_ENABLE_PROJECTS=openmp build mode#152189
Merged
Meinersbur merged 6 commits intollvm:mainfrom Jan 8, 2026
Merged
[OpenMP] Remove LLVM_ENABLE_PROJECTS=openmp build mode#152189Meinersbur merged 6 commits intollvm:mainfrom
Meinersbur merged 6 commits intollvm:mainfrom
Conversation
Collaborator
efriedma-quic
left a comment
efriedma-quic
left a comment
There was a problem hiding this comment.
llvm/utils/release/build_llvm_release.bat and clang/utils/analyzer/entrypoint.py also mention LLVM_ENABLE_PROJECTS=openmp .
This was referenced Aug 28, 2025
Meinersbur
added a commit
that referenced
this pull request
Nov 12, 2025
The LLVM-customized GTest has a dependency on LLVM to support `llvm::raw_ostream` and hence has to link to LLVMSupport. The runtimes use the LLVMSupport from the bootstrapping LLVM build. The problem is that the boostrapping compiler and the runtimes target can diverge in their ABI, even in the runtimes default build. For instance, Clang is built using gcc which uses libstdc++, but the runtimes is built by Clang which can be configured to use libcxx by default. Altough it does not use gcc, this issue has caused [flang-aarch64-libcxx](https://lab.llvm.org/buildbot/#/builders/89)) to break, and is still (again?) broken. This patch makes the runtimes' GTest independent from LLVMSupport so we do not link any runtimes component with LLVM components. Runtime projects that use GTest unittests: * flang-rt * libc * compiler-rt: Adds `gtest-all.cpp` with [GTEST_NO_LLVM_SUPPORT=1](https://github.com/llvm/llvm-project/blob/f801b6f67ea896d6e4d2de38bce9a79689ceb254/compiler-rt/CMakeLists.txt#L723) to each unittest without using `llvm_gtest`. Not touched by this PR. * openmp: Handled by #159416. Not touched for now by this PR to avoid conflict. The current state of this PR tries to reuse https://github.com/llvm/llvm-project/blob/main/third-party/unittest/CMakeLists.txt as much as possible, altough personally I would prefer to make it use "modern CMake" style. third-party/unittest/CMakeLists.txt will detect whether it is used in runtimes build and adjaust accordingly. It creates a different target for LLVM (`llvm_gtest`, NFCI) and another one for the runtimes (`runtimes_gtest`). It is not possible to reuse `llvm_gtest` for both since `llvm_gtest` is imported using `find_package(LLVM)` if configured using LLVM_INSTALL_GTEST. An alias `default_gtest` is used to select between the two. `default_gtest` could also be used for openmp which also supports standalone and [LLVM_ENABLE_PROJECTS](#152189) build mode.
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Nov 12, 2025
The LLVM-customized GTest has a dependency on LLVM to support `llvm::raw_ostream` and hence has to link to LLVMSupport. The runtimes use the LLVMSupport from the bootstrapping LLVM build. The problem is that the boostrapping compiler and the runtimes target can diverge in their ABI, even in the runtimes default build. For instance, Clang is built using gcc which uses libstdc++, but the runtimes is built by Clang which can be configured to use libcxx by default. Altough it does not use gcc, this issue has caused [flang-aarch64-libcxx](https://lab.llvm.org/buildbot/#/builders/89)) to break, and is still (again?) broken. This patch makes the runtimes' GTest independent from LLVMSupport so we do not link any runtimes component with LLVM components. Runtime projects that use GTest unittests: * flang-rt * libc * compiler-rt: Adds `gtest-all.cpp` with [GTEST_NO_LLVM_SUPPORT=1](https://github.com/llvm/llvm-project/blob/f801b6f67ea896d6e4d2de38bce9a79689ceb254/compiler-rt/CMakeLists.txt#L723) to each unittest without using `llvm_gtest`. Not touched by this PR. * openmp: Handled by #159416. Not touched for now by this PR to avoid conflict. The current state of this PR tries to reuse https://github.com/llvm/llvm-project/blob/main/third-party/unittest/CMakeLists.txt as much as possible, altough personally I would prefer to make it use "modern CMake" style. third-party/unittest/CMakeLists.txt will detect whether it is used in runtimes build and adjaust accordingly. It creates a different target for LLVM (`llvm_gtest`, NFCI) and another one for the runtimes (`runtimes_gtest`). It is not possible to reuse `llvm_gtest` for both since `llvm_gtest` is imported using `find_package(LLVM)` if configured using LLVM_INSTALL_GTEST. An alias `default_gtest` is used to select between the two. `default_gtest` could also be used for openmp which also supports standalone and [LLVM_ENABLE_PROJECTS](llvm/llvm-project#152189) build mode.
git-crd
pushed a commit
to git-crd/crd-llvm-project
that referenced
this pull request
Nov 13, 2025
The LLVM-customized GTest has a dependency on LLVM to support `llvm::raw_ostream` and hence has to link to LLVMSupport. The runtimes use the LLVMSupport from the bootstrapping LLVM build. The problem is that the boostrapping compiler and the runtimes target can diverge in their ABI, even in the runtimes default build. For instance, Clang is built using gcc which uses libstdc++, but the runtimes is built by Clang which can be configured to use libcxx by default. Altough it does not use gcc, this issue has caused [flang-aarch64-libcxx](https://lab.llvm.org/buildbot/#/builders/89)) to break, and is still (again?) broken. This patch makes the runtimes' GTest independent from LLVMSupport so we do not link any runtimes component with LLVM components. Runtime projects that use GTest unittests: * flang-rt * libc * compiler-rt: Adds `gtest-all.cpp` with [GTEST_NO_LLVM_SUPPORT=1](https://github.com/llvm/llvm-project/blob/f801b6f67ea896d6e4d2de38bce9a79689ceb254/compiler-rt/CMakeLists.txt#L723) to each unittest without using `llvm_gtest`. Not touched by this PR. * openmp: Handled by llvm#159416. Not touched for now by this PR to avoid conflict. The current state of this PR tries to reuse https://github.com/llvm/llvm-project/blob/main/third-party/unittest/CMakeLists.txt as much as possible, altough personally I would prefer to make it use "modern CMake" style. third-party/unittest/CMakeLists.txt will detect whether it is used in runtimes build and adjaust accordingly. It creates a different target for LLVM (`llvm_gtest`, NFCI) and another one for the runtimes (`runtimes_gtest`). It is not possible to reuse `llvm_gtest` for both since `llvm_gtest` is imported using `find_package(LLVM)` if configured using LLVM_INSTALL_GTEST. An alias `default_gtest` is used to select between the two. `default_gtest` could also be used for openmp which also supports standalone and [LLVM_ENABLE_PROJECTS](llvm#152189) build mode.
llvmbot
added
clang:static analyzer
flang
Member
|
@llvm/pr-subscribers-clang-static-analyzer-1 @llvm/pr-subscribers-github-workflow Author: Michael Kruse (Meinersbur) ChangesThe build mode has been deprecated in #136314. According to the deprecation message, it was supposed to be removed in the LLVM 21 release. Each build mode increased the maintanance overhead when failing, such as in #151117. Let's remove it in LLVM 22. Full diff: https://github.com/llvm/llvm-project/pull/152189.diff 7 Files Affected:
diff --git a/.github/workflows/docs.yml b/.github/workflows/docs.yml
index 1b1f027be1a7e..1fe382120c76b 100644
--- a/.github/workflows/docs.yml
+++ b/.github/workflows/docs.yml
@@ -186,10 +186,10 @@ jobs:
steps.docs-changed-subprojects.outputs.openmp_any_changed == 'true' ||
steps.docs-changed-subprojects.outputs.workflow_any_changed == 'true'
run: |
- cmake -B openmp-build -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;openmp" -DLLVM_ENABLE_SPHINX=ON ./llvm
+ cmake -B openmp-build -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_RUNTIMES="openmp" -DLLVM_ENABLE_SPHINX=ON ./runtimes
TZ=UTC ninja -C openmp-build docs-openmp-html
mkdir built-docs/openmp
- cp -r openmp-build/docs/* built-docs/openmp/
+ cp -r openmp-build/openmp/docs/* built-docs/openmp/
- name: Build Polly docs
if: |
steps.docs-changed-subprojects.outputs.polly_any_changed == 'true' ||
diff --git a/clang/utils/analyzer/entrypoint.py b/clang/utils/analyzer/entrypoint.py
index c8dfc1a9f2ed8..ef8f20c7f0b01 100644
--- a/clang/utils/analyzer/entrypoint.py
+++ b/clang/utils/analyzer/entrypoint.py
@@ -53,7 +53,7 @@ def is_cmake_needed():
CMAKE_COMMAND = (
"cmake -G Ninja -DCMAKE_BUILD_TYPE=Release "
"-DCMAKE_INSTALL_PREFIX=/analyzer -DLLVM_TARGETS_TO_BUILD=X86 "
- '-DLLVM_ENABLE_PROJECTS="clang;openmp" -DLLVM_BUILD_RUNTIME=OFF '
+ '-DLLVM_ENABLE_PROJECTS="clang" -DLLVM_BUILD_RUNTIME=OFF '
"-DCLANG_ENABLE_STATIC_ANALYZER=ON"
)
diff --git a/flang-rt/README.md b/flang-rt/README.md
index 4fe66a85a269c..eecb7b8cbfdfd 100644
--- a/flang-rt/README.md
+++ b/flang-rt/README.md
@@ -58,8 +58,8 @@ not provide all C-ABI functionality (such as Windows).
cmake -S <path-to-llvm-project-source>/llvm \
-GNinja \
-DCMAKE_BUILD_TYPE=Release \
- -DLLVM_ENABLE_PROJECTS="clang;flang;openmp" \
- -DLLVM_ENABLE_RUNTIMES="compiler-rt;flang-rt" \
+ -DLLVM_ENABLE_PROJECTS="clang;flang" \
+ -DLLVM_ENABLE_RUNTIMES="compiler-rt;flang-rt;openmp" \
...
```
diff --git a/flang/tools/f18/CMakeLists.txt b/flang/tools/f18/CMakeLists.txt
index 58ea782ce213e..ffd92f033840b 100644
--- a/flang/tools/f18/CMakeLists.txt
+++ b/flang/tools/f18/CMakeLists.txt
@@ -135,18 +135,7 @@ if (NOT CMAKE_CROSSCOMPILING)
# Special case for omp_lib.mod, because its source comes from openmp/runtime/src/include.
# It also produces two module files: omp_lib.mod and omp_lib_kinds.mod. Compile these
# files only if OpenMP support has been configured.
- if (LLVM_TOOL_OPENMP_BUILD)
- message(STATUS "OpenMP runtime support enabled via LLVM_ENABLE_PROJECTS, building omp_lib.mod")
- set(base ${FLANG_INTRINSIC_MODULES_DIR}/omp_lib)
- add_custom_command(OUTPUT ${base}.mod ${base}_kinds.mod
- COMMAND ${CMAKE_COMMAND} -E make_directory ${FLANG_INTRINSIC_MODULES_DIR}
- COMMAND flang -cpp -fsyntax-only ${opts} -module-dir ${FLANG_INTRINSIC_MODULES_DIR}
- ${CMAKE_BINARY_DIR}/projects/openmp/runtime/src/omp_lib.F90
- DEPENDS flang ${FLANG_INTRINSIC_MODULES_DIR}/iso_c_binding.mod ${CMAKE_BINARY_DIR}/projects/openmp/runtime/src/omp_lib.F90 ${depends}
- )
- list(APPEND MODULE_FILES ${base}.mod ${base}_kinds.mod)
- install(FILES ${base}.mod ${base}_kinds.mod DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}/flang" COMPONENT flang-module-interfaces)
- elseif ("openmp" IN_LIST LLVM_ENABLE_RUNTIMES)
+ if ("openmp" IN_LIST LLVM_ENABLE_RUNTIMES)
message(STATUS "OpenMP runtime support enabled via LLVM_ENABLE_RUNTIMES, assuming omp_lib.mod is built there")
else()
message(WARNING "Not building omp_lib.mod, no OpenMP runtime in either LLVM_ENABLE_PROJECTS or LLVM_ENABLE_RUNTIMES")
@@ -160,11 +149,7 @@ set_target_properties(module_files PROPERTIES FOLDER "Flang/Resources")
# TODO Move this to a more suitable location
# Copy the generated omp_lib.h header file, if OpenMP support has been configured.
-if (LLVM_TOOL_OPENMP_BUILD)
- message(STATUS "OpenMP runtime support enabled via LLVM_ENABLE_PROJECTS, building omp_lib.h")
- file(COPY ${CMAKE_BINARY_DIR}/projects/openmp/runtime/src/omp_lib.h DESTINATION "${CMAKE_BINARY_DIR}/include/flang/OpenMP/" FILE_PERMISSIONS OWNER_READ OWNER_WRITE)
- install(FILES ${CMAKE_BINARY_DIR}/include/flang/OpenMP/omp_lib.h DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}/flang/OpenMP")
-elseif ("openmp" IN_LIST LLVM_ENABLE_RUNTIMES)
+if ("openmp" IN_LIST LLVM_ENABLE_RUNTIMES)
message(STATUS "OpenMP runtime support enabled via LLVM_ENABLE_RUNTIMES, assuming omp_lib.h is built there")
else()
message(STATUS "Not copying omp_lib.h, no OpenMP runtime in either LLVM_ENABLE_PROJECTS or LLVM_ENABLE_RUNTIMES")
diff --git a/llvm/CMakeLists.txt b/llvm/CMakeLists.txt
index f0e4f5d7d6f60..0cbb571495269 100644
--- a/llvm/CMakeLists.txt
+++ b/llvm/CMakeLists.txt
@@ -109,12 +109,7 @@ endif()
# This allows an easy way of setting up a build directory for llvm and another
# one for llvm+clang+... using the same sources.
# These projects will be included when "all" is included in LLVM_ENABLE_PROJECTS.
-set(LLVM_ALL_PROJECTS "bolt;clang;clang-tools-extra;compiler-rt;cross-project-tests;libclc;lld;lldb;mlir;openmp;polly")
-if ("${CMAKE_SYSTEM_NAME}" MATCHES "AIX")
- # Disallow 'openmp' as a LLVM PROJECT on AIX as the supported way is to use
- # LLVM_ENABLE_RUNTIMES.
- list(REMOVE_ITEM LLVM_ALL_PROJECTS openmp)
-endif()
+set(LLVM_ALL_PROJECTS "bolt;clang;clang-tools-extra;compiler-rt;cross-project-tests;libclc;lld;lldb;mlir;polly")
# The "libc" project, which is not part of "all" projects, could be included in
# LLVM_ENABLE_PROJECTS. It is preferred to include "libc" in
@@ -131,6 +126,15 @@ if( LLVM_ENABLE_PROJECTS STREQUAL "all" )
set( LLVM_ENABLE_PROJECTS ${LLVM_ALL_PROJECTS})
endif()
+if ("openmp" IN_LIST LLVM_ENABLE_PROJECTS)
+ message(FATAL_ERROR "
+Support for the LLVM_ENABLE_PROJECTS=openmp build mode has been removed. Please switch to the bootstrapping build
+ cmake -S <llvm-project>/llvm -B build -DLLVM_ENABLE_PROJECTS=clang -DLLVM_ENABLE_RUNTIMES=openmp
+or to the runtimes default build
+ cmake -S <llvm-project>/runtimes -B build -DLLVM_ENABLE_RUNTIMES=openmp
+")
+endif()
+
foreach(proj ${LLVM_ENABLE_PROJECTS})
if (NOT proj STREQUAL "llvm" AND NOT "${proj}" IN_LIST LLVM_KNOWN_PROJECTS)
MESSAGE(FATAL_ERROR "${proj} isn't a known project: ${LLVM_KNOWN_PROJECTS}. Did you mean to enable it as a runtime in LLVM_ENABLE_RUNTIMES?")
@@ -200,13 +204,6 @@ if ("offload" IN_LIST LLVM_ENABLE_PROJECTS)
"https://openmp.llvm.org/ for building the runtimes.")
endif()
-if ("openmp" IN_LIST LLVM_ENABLE_PROJECTS)
- message(WARNING "Using LLVM_ENABLE_PROJECTS=openmp is deprecated now, and will "
- "become a fatal error in a future release. Please use "
- "-DLLVM_ENABLE_RUNTIMES=openmp or see the instructions at "
- "https://openmp.llvm.org/ for building the runtimes.")
-endif()
-
if ("flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
if (NOT "flang" IN_LIST LLVM_ENABLE_PROJECTS)
message(FATAL_ERROR "Flang is not enabled, but is required for the Flang-RT runtime")
diff --git a/llvm/runtimes/CMakeLists.txt b/llvm/runtimes/CMakeLists.txt
index 1302334777613..c5d1417ce583c 100644
--- a/llvm/runtimes/CMakeLists.txt
+++ b/llvm/runtimes/CMakeLists.txt
@@ -688,13 +688,6 @@ if(build_runtimes)
# We need to add the runtimes as a dependency because compiler-rt can be
# built as part of runtimes and we need the profile runtime for PGO
add_dependencies(clang-bootstrap-deps runtimes)
- # The bootstrap build will attempt to configure the offload runtime
- # before the openmp project which will error out due to failing to
- # find libomp.so. We must add omp as a dependency before runtimes
- # are configured.
- if("openmp" IN_LIST LLVM_ENABLE_PROJECTS AND "offload" IN_LIST LLVM_ENABLE_RUNTIMES)
- add_dependencies(clang-bootstrap-deps omp)
- endif()
endif()
if(LLVM_INCLUDE_TESTS)
diff --git a/openmp/docs/ReleaseNotes.rst b/openmp/docs/ReleaseNotes.rst
index 6c1a46caf1d81..b99947540acd7 100644
--- a/openmp/docs/ReleaseNotes.rst
+++ b/openmp/docs/ReleaseNotes.rst
@@ -27,3 +27,4 @@ Device Runtime
always build support for AMDGPU and NVPTX targets.
- Updated the offloading entry format but retained backwards compatibility with
the old format.
+- The LLVM_ENABLE_PROJECTS=openmp build mode has been removed.
\ No newline at end of file
|
Member
Author
|
Removed draft status to continue working on this. Related PRs: |
mgorny
approved these changes
Jan 7, 2026
Member
mgorny
left a comment
mgorny
left a comment
There was a problem hiding this comment.
Don't see anything wrong with it. We're not using it in Gentoo, so nothing to test on my end.
Contributor
|
As long as we keep support standalone build for |
Contributor
Do you mean, supporting standalone builds or the literal standalone build. Because I'd really prefer to get rid of the current standalone build for both. It doesn't really net us anything but more testing configurations. |
Contributor
|
Like I have mentioned many times in the past, most of |
Contributor
Old: New: I don't think this is an unreasonable change as long as we document it. We can probably put an error message in the top level to point to some documentation. |
Member
Author
There is also |
Member
Author
Contributor
|
What I meant is, |
Member
Author
Using a default runtimes build the only caveat is you have to add
I strongly object to maintaining redundant build configurations. We had autoconf+cmake before, no need to add extra maintainance overhead. I am often thinking about cleaning up openmp's CMake code, but having to keep so many build modes working stops me from doing it. This discussion is off-topic. This PR is about LlVM_ENABLE_PROJECTS=openmp, not standalone build mode. |
Member
Author
How is this relevant? libc++was also bootstrapped before it became an LLVM subproject. And even after that it lived in a separate SVN repository. |
Contributor
|
If the CMake arguments are the same, I can live with that but we do need to update the project README as well as some error information to reflect this properly. |
Contributor
Yeah, we should 100% update documentation. Projects should already recommend runtimes, for the 'standlone' we should have some documentation online and the current code that detects standalone should print a fatal error pointing to that documentation @estewart08 |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/45/builds/21068 Here is the relevant piece of the build log for the reference |
Meinersbur
added a commit
that referenced
this pull request
Jan 8, 2026
…)" This reverts commit 20d0ec8. The publish-sphinx-docs buildbot still uses LLVM_ENABLE_PROJECTS=openmp.
Meinersbur
added a commit
that referenced
this pull request
Jan 8, 2026
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/27/builds/21213 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/95/builds/19685 Here is the relevant piece of the build log for the reference |
kshitijvp
pushed a commit
to kshitijvp/llvm-project
that referenced
this pull request
Jan 9, 2026
The build mode has been deprecated in llvm#136314. According to the deprecation message, it was supposed to be removed in the LLVM 21 release. Each build mode increased the maintanance overhead when failing, such as in llvm#151117. Let's remove it in LLVM 22.
Member
Author
See #176175 |
Priyanshu3820
pushed a commit
to Priyanshu3820/llvm-project
that referenced
this pull request
Jan 18, 2026
The build mode has been deprecated in llvm#136314. According to the deprecation message, it was supposed to be removed in the LLVM 21 release. Each build mode increased the maintanance overhead when failing, such as in llvm#151117. Let's remove it in LLVM 22.
Priyanshu3820
pushed a commit
to Priyanshu3820/llvm-project
that referenced
this pull request
Jan 18, 2026
tbaederr
pushed a commit
to tbaederr/llvm-project
that referenced
this pull request
Jan 20, 2026
Reapply llvm#152189 which was reverted because it broke publish-sphinx-docs. The build mode has been deprecated in llvm#136314. According to the deprecation message, it was supposed to be removed in the LLVM 21 release. Each build mode increased the maintanance overhead when failing, such as in llvm#151117.
This was referenced Jan 20, 2026
BStott6
pushed a commit
to BStott6/llvm-project
that referenced
this pull request
Jan 22, 2026
Reapply llvm#152189 which was reverted because it broke publish-sphinx-docs. The build mode has been deprecated in llvm#136314. According to the deprecation message, it was supposed to be removed in the LLVM 21 release. Each build mode increased the maintanance overhead when failing, such as in llvm#151117.
Meinersbur
added a commit
that referenced
this pull request
Jan 30, 2026
Reapply #152189 and #174963 which were reverted because it broke publish-sphinx-docs and publish-doxygen-docs. The build mode has been deprecated in #136314 and was supposed to be removed in the LLVM 21 release (#136314). OpenMP currently supports 4 build modes: * `cmake <llvm-project>/llvm -DLLVM_ENABLE_PROJECTS=openmp` * `cmake <llvm-project>/llvm -DLLVM_ENABLE_RUNTIMES=openmp` (bootstrapping build) * `cmake <llvm-project>/openmp` (standalone build) * `cmake <llvm-project>/runtimes -DLLVM_ENABLE_RUNTIMES=openmp` (runtimes default/standalone build) Each build mode increased the maintanance overhead since all build modes must continue working and user confusion when there do not (see #151117, #174126, #154117, ...). Let's finally remove it.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
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.
The build mode has been deprecated in #136314. According to the deprecation message, it was supposed to be removed in the LLVM 21 release. Each build mode increased the maintanance overhead when failing, such as in #151117.
Let's remove it in LLVM 22.