[Flang] Move builtin .mod generation into runtimes #137828
Merged
Conversation
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
jhuber6
reviewed
Apr 29, 2025
Contributor
jhuber6
left a comment
jhuber6
left a comment
There was a problem hiding this comment.
What's the main limitation here? If this is just a file dependency it should be identical to how all the OpenMP tests depend on omp.h being in the resource directory. IMHO this is trivial if we do a runtimes build, since we can just require that openmp;flang-rt are in the same toolchain, which then gives us well defined access to openmp's CMake targets so long as it's listed before flang-rt.
Member
Author
|
While I appreciate the review, it is not yet in the state that warants one. It is still in an experimentation stage, so I did not yet care about formatting. There are also a lot of changes in here that will eventually not be needed. Goals are:
Sounds relatively simple, but there have been many small issues, starting with CMake's misspelling of CMAKE_Fortran_BUILDING_INSTRINSIC_MODULES. |
Contributor
Just want to make sure: Should it be |
Member
Author
That is correct, I forgot the version number that is part of the resource directory. |
DanielCChen
reviewed
May 7, 2025
Meinersbur
force-pushed
the
flang_builtin-mods
branch
from
907d3d5 to
839198d
Compare
|
✅ With the latest revision this PR passed the Python code formatter. |
Member
Author
With toolchain you mean a bootstrapping build with
|
Collaborator
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/203/builds/30105 Here is the relevant piece of the build log for the reference |
Collaborator
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/206/builds/9559 Here is the relevant piece of the build log for the reference |
Collaborator
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/129/builds/33821 Here is the relevant piece of the build log for the reference |
|
Hi @Meinersbur, I don't know if this is the right way to approach this (I could open a new issue also), but I'm trying here first. I have been waiting for this to be merged as I believe it would possibly solve my issue #146876 (I think there are at least two other related issue in the tracker as well). I have now build the commit 86fbaef form the main branch, and I see the module files in Do I miss something obvious? Do we need to set some new CMake flags/options compared to previous for this to be built correctly? |
Contributor
|
We see this breaking our buildbot in https://lab.llvm.org/staging/#/builders/105/builds/37275 I'm going to open a revert PR. |
Member
Author
|
@hakostra Modules for other targets must be build explicitly, e.g. Without this PR, modules files are shared between all targets, i.e. both are using the same module files. For instance x86_64 has a |
jplehr
added a commit
that referenced
this pull request
Nov 25, 2025
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Nov 25, 2025
…" (#169489) Reverts llvm/llvm-project#137828 Buildbot error in https://lab.llvm.org/staging/#/builders/105/builds/37275
Contributor
|
@Meinersbur , with a potentially disruptive change like this, it would have been helpful to send a heads-up to flang discourse, describing what's about to be merged, what are potential implications and how to handle them. And also add the same notice as a comment to this PR, so people could find it and deal with the fallout. |
Contributor
The last message on that thread was on Feb 13. What I'm saying is send a fresh note to make people aware that it's going in now/soon and be prepared to do steps x/y/z to deal with fallout. |
This was referenced Nov 25, 2025
Collaborator
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/95/builds/19222 Here is the relevant piece of the build log for the reference |
Contributor
|
Hi @Meinersbur, since this PR was reverted, I am not sure when you plan to try to merge it back - can you please let me know? Can you please postpone merging this until the next week? Many people in US are out due to the Thanksgiving, and there might be some downstream failures that will have to be addressed in a timely manner. |
Member
Author
Contributor
|
Thank you, @Meinersbur! Sorry, I only reviewed/tried your patch at its earlt stages and I haven't been following the recent updates. I will try it again today and will report any comments in the new PR. |
augusto2112
pushed a commit
to augusto2112/llvm-project
that referenced
this pull request
Dec 3, 2025
Move building the .mod files from openmp/flang to openmp/flang-rt using a shared mechanism. Motivations to do so are: 1. Most modules are target-dependent and need to be re-compiled for each target separately, which is something the LLVM_ENABLE_RUNTIMES system already does. Prime example is `iso_c_binding.mod` which encodes the target's ABI. Most other modules have `#ifdef`-enclosed code as well. 2. CMake has support for Fortran that we should use. Among other things, it automatically determines module dependencies so there is no need to hardcode them in the CMakeLists.txt. 3. It allows using Fortran itself to implement Flang-RT. Currently, only `iso_fortran_env_impl.f90` emits object files that are needed by Fortran applications (llvm#89403). The workaround of llvm#95388 could be reverted. Some new dependencies come into play: * openmp depends on flang-rt for building `lib_omp.mod` and `lib_omp_kinds.mod`. Currently, if flang-rt is not found then the modules are not built. * check-flang depends on flang-rt: If not found, the majority of tests are disabled. If not building in a bootstrpping build, the location of the module files can be pointed to using `-DFLANG_INTRINSIC_MODULES_DIR=<path>`, e.g. in a flang-standalone build. Alternatively, the test needing any of the intrinsic modules could be marked with `REQUIRES: flangrt-modules`. * check-flang depends on openmp: Not a change; tests requiring `lib_omp.mod` and `lib_omp_kinds.mod` those are already marked with `openmp_runtime`. As intrinsic are now specific to the target, their location is moved from `include/flang` to `<resource-dir>/finclude/flang/<triple>`. The mechnism to compute the location have been moved from flang-rt (previously used to compute the location of `libflang_rt.*.a`) to common locations in `cmake/GetToolchainDirs.cmake` and `runtimes/CMakeLists.txt` so they can be used by both, openmp and flang-rt. Potentially the mechnism could also be shared by other libraries such as compiler-rt. `finclude` was chosen because `gfortran` uses it as well and avoids misuse such as `#include <flang/iso_c_binding.mod>`. The search location is now determined by `ToolChain` in the driver, instead of by the frontend. Now the driver adds `-fintrinsic-module-path` for that location to the frontend call (Just like gfortran does). `-fintrinsic-module-path` had to be fixed for this because ironically it was only added to `searchDirectories`, but not `intrinsicModuleDirectories_`. Since the driver determines the location, tests invoking `flang -fc1` and `bbc` must also be passed the location by llvm-lit. This works like llvm-lit does for finding the include dirs for Clang using `-print-file-name=...`.
augusto2112
pushed a commit
to augusto2112/llvm-project
that referenced
this pull request
Dec 3, 2025
kcloudy0717
pushed a commit
to kcloudy0717/llvm-project
that referenced
this pull request
Dec 4, 2025
Move building the .mod files from openmp/flang to openmp/flang-rt using a shared mechanism. Motivations to do so are: 1. Most modules are target-dependent and need to be re-compiled for each target separately, which is something the LLVM_ENABLE_RUNTIMES system already does. Prime example is `iso_c_binding.mod` which encodes the target's ABI. Most other modules have `#ifdef`-enclosed code as well. 2. CMake has support for Fortran that we should use. Among other things, it automatically determines module dependencies so there is no need to hardcode them in the CMakeLists.txt. 3. It allows using Fortran itself to implement Flang-RT. Currently, only `iso_fortran_env_impl.f90` emits object files that are needed by Fortran applications (llvm#89403). The workaround of llvm#95388 could be reverted. Some new dependencies come into play: * openmp depends on flang-rt for building `lib_omp.mod` and `lib_omp_kinds.mod`. Currently, if flang-rt is not found then the modules are not built. * check-flang depends on flang-rt: If not found, the majority of tests are disabled. If not building in a bootstrpping build, the location of the module files can be pointed to using `-DFLANG_INTRINSIC_MODULES_DIR=<path>`, e.g. in a flang-standalone build. Alternatively, the test needing any of the intrinsic modules could be marked with `REQUIRES: flangrt-modules`. * check-flang depends on openmp: Not a change; tests requiring `lib_omp.mod` and `lib_omp_kinds.mod` those are already marked with `openmp_runtime`. As intrinsic are now specific to the target, their location is moved from `include/flang` to `<resource-dir>/finclude/flang/<triple>`. The mechnism to compute the location have been moved from flang-rt (previously used to compute the location of `libflang_rt.*.a`) to common locations in `cmake/GetToolchainDirs.cmake` and `runtimes/CMakeLists.txt` so they can be used by both, openmp and flang-rt. Potentially the mechnism could also be shared by other libraries such as compiler-rt. `finclude` was chosen because `gfortran` uses it as well and avoids misuse such as `#include <flang/iso_c_binding.mod>`. The search location is now determined by `ToolChain` in the driver, instead of by the frontend. Now the driver adds `-fintrinsic-module-path` for that location to the frontend call (Just like gfortran does). `-fintrinsic-module-path` had to be fixed for this because ironically it was only added to `searchDirectories`, but not `intrinsicModuleDirectories_`. Since the driver determines the location, tests invoking `flang -fc1` and `bbc` must also be passed the location by llvm-lit. This works like llvm-lit does for finding the include dirs for Clang using `-print-file-name=...`.
kcloudy0717
pushed a commit
to kcloudy0717/llvm-project
that referenced
this pull request
Dec 4, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
12 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.
Move building the .mod files from openmp/flang to openmp/flang-rt using a shared mechanism. Motivations to do so are:
Most modules are target-dependent and need to be re-compiled for each target separately, which is something the LLVM_ENABLE_RUNTIMES system already does. Prime example is
iso_c_binding.modwhich encodes the target's ABI. Most other modules have#ifdef-enclosed code as well.CMake has support for Fortran that we should use. Among other things, it automatically determines module dependencies so there is no need to hardcode them in the CMakeLists.txt.
It allows using Fortran itself to implement Flang-RT. Currently, only
iso_fortran_env_impl.f90emits object files that are needed by Fortran applications ([flang] Linker for non-constant accesses to kind arrays (integer_kind, logical_kind, real_kind) #89403). The workaround of [flang][runtime] Build ISO_FORTRAN_ENV to export kind arrays as linkable symbols #95388 could be reverted.Some new dependencies come into play:
lib_omp.modandlib_omp_kinds.mod. Currently, if flang-rt is not found then the modules are not built.-DFLANG_INTRINSIC_MODULES_DIR=<path>, e.g. in a flang-standalone build. Alternatively, the test needing any of the intrinsic modules could be marked withREQUIRES: flangrt-modules.lib_omp.modandlib_omp_kinds.modthose are already marked withopenmp_runtime.As intrinsic are now specific to the target, their location is moved from
include/flangto<resource-dir>/finclude/flang/<triple>. The mechnism to compute the location have been moved from flang-rt (previously used to compute the location oflibflang_rt.*.a) to common locations incmake/GetToolchainDirs.cmakeandruntimes/CMakeLists.txtso they can be used by both, openmp and flang-rt. Potentially the mechnism could also be shared by other libraries such as compiler-rt.fincludewas chosen becausegfortranuses it as well and avoids misuse such as#include <flang/iso_c_binding.mod>. The search location is now determined byToolChainin the driver, instead of by the frontend. Now the driver adds-fintrinsic-module-pathfor that location to the frontend call (Just like gfortran does).-fintrinsic-module-pathhad to be fixed for this because ironically it was only added tosearchDirectories, but notintrinsicModuleDirectories_. Since the driver determines the location, tests invokingflang -fc1andbbcmust also be passed the location by llvm-lit. This works like llvm-lit does for finding the include dirs for Clang using-print-file-name=....Related PRs:
SHELL:workaround)