I first tried to build LLVM (the fork mentioned in the Wiki) on plain Windows. But at some point the “../..” notation got in the way, as I got the error message that “..” was not a known program or command.
So, I switched to WSL and after a long CMake session (it took literally two hours to complete), I got the set of makefiles that ought to do the trick. Alas, that failed on a compile error:
I think you might have fallen for the “classic flang” vs “new/LLVM flang” pitfall. If you weren’t aware, “classic flang” is the old PGI/NVidia compiler frontend (pgfortran) open-sourced and ported to use LLVM as the backend, and is developed separately from LLVM. “New flang” or “LLVM flang” is developed as part of the LLVM project, and is much more integrated into LLVM. They have been saying for several years that “classic flang” will somehow merge into “new flang”.
(Obviously depending on hardware, but) the Flang build times can be dropped dramatically with shared libs and optimized tablegen. Here’s what I use for building a (nominally usable for AMD GPUs with OpenMP) “main” version of Flang from source on Linux, which includes support for LIT and llvm-test-suite testing. It’s about 25 minutes for a clean build on my AMD Ryzen desktop. cmake -G “Ninja” -DBUILD_SHARED_LIBS=On -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DCMAKE_C_FLAGS=-march=native -DCMAKE_CXX_FLAGS=-march=native -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCOMPILER_RT_BUILD_XRAY=ON -DFLANG_ENABLE_WERROR=ON -DFLANG_RUNTIME_F128_MATH_LIB=libquadmath -DFLANG_RT_INCLUDE_TESTS=On -DLLVM_BUILD_DOCS=OFF -DLLVM_BUILD_EXAMPLES=OFF -DLLVM_BUILD_TESTS=On -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-gnu -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_DOXYGEN=OFF -DLLVM_ENABLE_IDE=ON -DLLVM_ENABLE_PROJECTS=“clang;lld;mlir;flang;clang-tools-extra” -DLLVM_ENABLE_RUNTIMES=“compiler-rt;openmp;libunwind” -DLLVM_ENABLE_SPHINX=OFF -DLLVM_INCLUDE_TESTS=On -DLLVM_OPTIMIZED_TABLEGEN=ON -DLLVM_LIT_ARGS=“-v --xunit-xml-output test-results.xml” -DLLVM_PARALLEL_LINK_JOBS=12 -DLLVM_TARGETS_TO_BUILD=“X86;AMDGPU” -DLLVM_USE_LINKER=lld -DRUNTIMES_amdgcn-amd-amdhsa_LLVM_ENABLE_RUNTIMES=“compiler-rt;libc;libcxx;libcxxabi;flang-rt;openmp” -DRUNTIMES_amdgcn-amd-amdhsa_FLANG_RT_LIBC_PROVIDER=“llvm” -DRUNTIMES_amdgcn-amd-amdhsa_FLANG_RT_LIBCXX_PROVIDER=“llvm” -DRUNTIMES_amdgcn-amd-amdhsa_CACHE_FILES=“${LLCM_SRC_DIR}/build/../libcxx/cmake/caches/AMDGPU.cmake” ../llvm
I think I remember someone mentioned here of installing using conda and/or homebrew. Not sure which version. I recently found after updating to the latest Linux Mint (Ubuntu 24.04 lts based) that llvm-20 (including new flang 20) is available directly from the standard repository. I don’t know if it includes GPU offloading though (probably doesn’t). Don’t know which version of Linux you are using under WSL but you might try a very recent Ubuntu or similar distribution. I think that LFortran 0.39 is also available.
Homebrew currently has flang 21.1.8 available as the latest stable version. According to https://llvm.org/, LLVM 22 should be released in the coming weeks (it’s currently in the release candidate phase).
Thanks for this information and these links. It is indeed the rather confusing distinction between “classic Flang” and “new Flang” that I have fallen victim to. Let me just start again and see how that works out.
Ah, that did the trick for installing flang, but if I try to build a (simple) program then flang complains about the run-time library flang_rt.runtime.static.lib:
flang hello.f90
LINK : fatal error LNK1104: cannot open file 'flang_rt.runtime.static.lib'
flang: error: linker command failed with exit code 1104 (use -v to see invocation)
There are reportedly packages “flang_rt-win-64” but these fail to be installed.
Also the installation as I have it now (I simply followed the instructions) lacks an omp_lib module.
You might also try checking if the problem is that the lib file does not exist or if it simply cannot be found by the linker. In the latter case, just add the respective folder to LIB.
N.B.: I use this script to install LLVM (especially flang) on GitHub-hosted runners (virtual machines). If you intend to use it on your own machine, check the code first.
You remotivated me to retry flang after so many fail attempts to get it actually working on a conda env on windows. While I couldn’t build stdlib with it because there are some missing features in the compiler, it did “work” in the sense of installing and building and reporting warnings and errors.
I’ll leave a few tips of what I had to do for reference:
Isolate the LLVM environment
conda create -n llvm
Install the required compiler, libraries and runtimes
For CMake, I hit a very tiny but annoying issue that took me some iterations to find, one has to declare clang-cl (not clang) as the C compiler if building outside a unix-like terminal for a MVSC-like behavior instead of GNU:
Interesting! I recently had to learn how to use flang exactly because it’s the default Fortran compiler in conda-forge for windows. It took me quite a lot of iterations to get it working, even though the result is quite simple.
If anyone is facing a similar challenge, just copy the approach used here.
@Arjen my apologies for any confusion. The ability for LLVM flang to offload do concurrent is experimental and under development. The work is far enough along that I suspect some cases can be offloaded if the compiler is built with OpenMP support and if the Fortran code is built with the right combination flags is passed, but even in those cases, it might require building a downstream fork of llvm-project. I occasionally meet with a compiler engineer who is working on flang’s do concurrent offloading support, but I haven’t tried it yet because I know it can’t offload the code that I most care about. As soon as flang can offload my code, I’ll test it and report back.
Most of the confusion was getting Flang to work on my machine I quite understand that a new compiler like Flang does not support everything yet. It was more of a surprise to see that compiling with OpenMP caused the CPUs to grind heavily on my sample program, whereas the directives did include offloading. It seems these parts were ignored. But those are very preliminary observations.