LLVM_ENABLE_RUNTIMES=flang-rt for flang-aarch64-out-of-tree #388
Conversation
Meinersbur
requested review from
gkistanova,
DavidSpickett,
luporl and
ceseo
Meinersbur
changed the title
There was a problem hiding this comment.
I have tested the changes on AArch64, but manually only, using cmake invocations extracted from these sources. There were no issues in the configure, build and check stages.
Overall the changes look good to me, but as I'm not very familiar with zorg, it would be better if someone else could review this PR too, especially the changes to clean build directories and those around enable_projects.
| # Use the Fortran compiler from the previous step. | ||
| flang_rt_cmake_args += [ | ||
| util.Interpolate( | ||
| f"-DCMAKE_Fortran_COMPILER=%(prop:builddir)s/{flang_obj_dir}/bin/flang" | ||
| ), | ||
| "-DCMAKE_Fortran_COMPILER_WORKS=ON", | ||
| ] |
There was a problem hiding this comment.
Don't we want to use the C/C++ compiler from the previous step too?
There was a problem hiding this comment.
This would be possible, but not necessary. We already many builders that are using the bootstrapping build (which by design use just-built Clang to build the runtime), keeping at least one that also tests compilation with gcc might be a good idea. The other one that explicitly uses gcc, flang-runtime-cuda-gcc, is a bootstrapping build, therefore effectively changed to use Clang to build flang-rt in #393.
There was a problem hiding this comment.
I assume that the existing bot does not use the clang from the previous step, so I'm in favour of leaving this as it is just for that reason.
We have other 2 stage bots that enable flang, and I expect most out of tree problems to be found by a single stage build anyway.
| # Use the Fortran compiler from the previous step. | ||
| flang_rt_cmake_args += [ | ||
| util.Interpolate( | ||
| f"-DCMAKE_Fortran_COMPILER=%(prop:builddir)s/{flang_obj_dir}/bin/flang" | ||
| ), | ||
| "-DCMAKE_Fortran_COMPILER_WORKS=ON", | ||
| ] |
There was a problem hiding this comment.
I assume that the existing bot does not use the clang from the previous step, so I'm in favour of leaving this as it is just for that reason.
We have other 2 stage bots that enable flang, and I expect most out of tree problems to be found by a single stage build anyway.
Make
FlangBuilder.getFlangOutOfTreeBuildFactorybuild the flang-rt runtime as an out-of-tree runtimes build with additional steps.Fixes some issues with FlangBuilder too:
flangandflang-rtas depends_on_projects. Otherwise, changes in these subdirectories do not trigger a build. Even worse, breaking commits will be attributed to the next commit in llvm/clang/mlir/openmp, as happed in e.g. https://lab.llvm.org/buildbot/#/builders/53/builds/11759 (commit causing failure was llvm/llvm-project@fe8b323)This PR is not strictly necessary for llvm/llvm-project#124126, it just wouldn't build the runtime anymore.
Affected builders:
Affected workers:
Verfied locally on x86_64.