[WIP] Add flang (Fortran) compiler support

[vtjnash]

This attempts to add the configuration needed to build and use flang on Windows. Mostly written by Claude since I don't have much familiarity with either this code or with flang/flang-rt specifically, so some things are probably done sub-optimally. The main fact here is just that this worked to build a flang cross compiler and relevant runtime libraries and then the result was able to build OpenBLAS and pass all of its self tests. Unfortunately there are a very small number of mistakes in flang-rt in v21 that mean it currently only supports building with MSVC headers, but that should get resolved soon in upstream llvm.

Change overview:

• Add flang to LLVM_ENABLE_PROJECTS in build-llvm.sh
• Add build-flang-rt.sh to build the Fortran runtime library
• Update install-wrappers.sh to create flang/gfortran symlinks
• Update clang-target-wrapper.c and clang-target-wrapper.sh to handle
  flang driver:
  • Uses flang binary directly (instead of clang --driver-mode=flang)
  • Adds --no-default-config to avoid C++-specific flags from config
    files causing flang to error
  • Add -rtlib=compiler-rt to use compiler-rt instead of libgcc (this
    seemed to make the linker complain about an unused argument, but
    also fixes the build to stop linking against -lgcc).
  • Pass through -fc1 invocations directly to avoid breaking frontend
    calls (calling *flang calls *flang -fc1, which got confused if
    we prepend any other arguments).
• Update strip-llvm.sh to preserve libMLIR, libFortran, and libflang
  shared libs.

Note: i686 and armv7 are excluded from flang-rt due to compile-time
asserts that failed due to 32-bit mistakes. The arm64ec is excluded as
we haven't tested if flang could be built for it.

Co-Authored-By: Claude Opus 4.5 [email protected]
Refs: #146, #163

[mstorsjo]

Thanks for this PR.

Just FWIW, I did investigate adding Flang already a couple of years ago - see https://github.com/mstorsjo/llvm-mingw/commits/flang. At the time there were numerous things that held it back - and even if it would have worked somewhat, it was quite inconvenient in many ways. There's been plenty of progress upstream now so things are probably much better now.

One issue that has been mentioned a couple of times, is that there are parts of Flang's code generation that doesn't work right for cross compilation - where aspects from the host environment affect the generated code. I don't remember the details around this (and I'm not sure how often the issue comes up, and how subtle it is), but I remember hearing about it still as late as February this year.

I'll try to have a look at these details when I can spare the time. And also FWIW, even if all the technical details would be right, I'm still undecided whether I'd like to actuall enable and include it in the end or not - Flang is so big that it quite significantly affects the amount of effort required to build all of LLVM.

[mati865]

FWIW, Flang can build many projects, as you can see at ("Required by" section): https://packages.msys2.org/packages/mingw-w64-clang-x86_64-flang
But not without some patches: https://github.com/msys2/MINGW-packages/tree/576fc4bbfa9bff4d5ab81779a706723b5214fd7d/mingw-w64-flang

[vtjnash]

I don't fully understand the purpose of many of those patches, since the first seems to be just working around msys2's own build system?The-municode` one is already fixed upstream (by llvm/llvm-project#160096). Is there an upstream PR for msys2/MINGW-packages#16579? If you have shown that is correct in general we can merge that upstream (edit: breadcrumb for the exact definition of long double across platforms: Windows-on-ARM-Experiments/mingw-woarm64-build#9 (comment))

I'd have thought you'd have more issues with the incorrect definition of long for Windows than of long double:
184d801fc4bbe (peter klausler 2019-05-31 16:35:52 -0700 46) c_long = c_int64_t, &
(edit 2: llvm/llvm-project#172034)

[vtjnash]

I'll try to have a look at these details when I can spare the time. And also FWIW, even if all the technical details would be right, I'm still undecided whether I'd like to actuall enable and include it in the end or not - Flang is so big that it quite significantly affects the amount of effort required to build all of LLVM.

I'm perfectly happy if you leave it disabled by default (I agree it is quite a beast to build right now, with flang-rt crashing my 32 GB WSL2 container and sometimes even the host hypervisor until I finally had given it enough swap and limited it to few enough cores to get through compiling those cpp files). My eventual goal is building docker-like containers that JuliaLang will then use to host CI builds on our existing infrastructure. Right now, I'm just trying to test what builds and what breaks at a request from Microsoft, in exchange for a laptop.

[mstorsjo]

I'm perfectly happy if you leave it disabled by default (I agree it is quite a beast to build right now, with flang-rt crashing my 32 GB WSL2 container and sometimes even the host hypervisor until I finally had given it enough swap and limited it to few enough cores to get through compiling those cpp files).

Oh - is flang-rt big and hard to build as well? A couple years ago when I played with it, the runtime wasn't big at all - but building Flang itself was problematic.

For building Flang, I would run out of RAM if building with GCC, while building with Clang worked much better. I had access to a 160 core/128 GB machine for building, and I had to lower than down to just 40 parallel build jobs to successfully be able to build it with GCC. (And building all of LLVM+LLD+Clang+Clang-tools-extra+LLDB+Flang at 1/4 of the number of parallel jobs makes things unnecessarily slow, when it's just this one part which is a bottleneck.)

[mati865]

I don't fully understand the purpose of many of those patches, since the first seems to be just working around msys2's own build system?The-municode` one is already fixed upstream (by llvm/llvm-project#160096). Is there an upstream PR for msys2/MINGW-packages#16579? If you have shown that is correct in general we can merge that upstream (edit: breadcrumb for the exact definition of long double across platforms: Windows-on-ARM-Experiments/mingw-woarm64-build#9 (comment))

I'd have thought you'd have more issues with the incorrect definition of long for Windows than of long double: 184d801fc4bbe (peter klausler 2019-05-31 16:35:52 -0700 46) c_long = c_int64_t, & (edit 2: llvm/llvm-project#172034)

Those fixes are not yet released, so llvm-mingw would also need to use patches, unless targeting next release only.
I didn't author those patches, and I don't know if they were upstreamed.