CMake: Check for known bad configurations with LLVM Flang

[mmuetzel]

Some features either don't compile or don't work correctly with LLVM Flang before version 17.
This PR tries to help users to avoid these known-bad configurations by emitting a message and adapting the corresponding flags.

It's still unclear if both of these known-bad configurations will actually be fixed in LLVM Flang 17 or if one of them is actually an issue that is platform-dependent (i.e., only Windows or MinGW). In the latter case, the conditions could still be adapted in the future.

The flags need to be adapted early on. At least, before system_check.cmake is included via system.cmake. That required to move the check for the Fortran compiler to earlier in the configuration process.

[mmuetzel]

Updated the PR and rebased on a current head.
Building with AVX512 still leads to failing tests with LLVM Flang 17 on Windows.

[MehdiChinoune]

Any update with flang-18.1?

[MehdiChinoune]

All tests pass with flang-18

[martin-frbg]

avx512 too ?

[MehdiChinoune]

avx512 too ?

I don't know, I haven't passed NO_AVX512 to cmake and It builds (after applying #4616) and all tests pass.
I don't have an AVX512 PC to test on.

[martin-frbg]

I see - actually passing the tests on an avx512 cpu used to be the problem with recent llvm, but I will probably not get to recheck this before monday

[mmuetzel]

Try again after MSYS2 updated to LLVM 19.

If I understand correctly, there was a lot of activity around LLVM Flang in OpenBLAS recently. I don't know which were the findings around compatible versions on which platform.

Please, let me know if I got some of the conditions wrong.

[martin-frbg]

My current understanding is that LLVM/flang works on non-Windows platforms since version 17, and on Windows since 19 (bar some small issues that may be misunderstandings on my part, which I hope to resolve this week).

[mmuetzel]

Do you recall what the situation was regarding OpenMP? I have a faint memory that something didn't yet work correctly with LLVM Flang 17 and LLVM libomp. (But it's very much possible, I'm remembering incorrectly.)

[martin-frbg]

ISTR flang17 did not yet have the necessary omp_lib module (at least early on) and possibly implementation issues on the C side too - in any case it does not seem far-fetched to me to require a fairly recent version of a compiler that is officially still not fully stable.

[mmuetzel]

in any case it does not seem far-fetched to me to require a fairly recent version of a compiler that is officially still not fully stable.

Sounds reasonable to me. 👍

With the proposed changes, CMake would disable AVX512 instructions with LLVM Flang before version 17 (on anything but Windows) or before version 19 (on Windows). OpenMP would be disabled for LLVM Flang before version 19 (on any operating system).

If I understand correctly, that more or less reflects what is actually supported when using that compiler.

Is the PR acceptable in this form?

[h-vetinari]

I think the easiest here might be to just error on flang <19 (or require an explicit opt-in with a scary CMake variable). Otherwise this seems like a good idea to me.

I think there's also still some CMake issues with CMake's openmp+fortran detection on flang. For our current openblas builds, we have to use

:: https://discourse.cmake.org/t/how-to-find-openmp-with-clang-on-macos/8860
set "CMAKE_EXTRA=-DOpenMP_ROOT=%LIBRARY_LIB%"
:: not picked up by `find_package(OpenMP)` for some reason
set "CMAKE_EXTRA=-DOpenMP_Fortran_FLAGS=-fopenmp -DOpenMP_Fortran_LIB_NAMES=libomp"

[martin-frbg]

I'm actually unsure right now if flang+openmp wasn't purely a Windows problem with flang18 , so excluding it for Linux and others would be a step backwards.
And given that the llvm team are planning to provide flang in their "official" Windows binary package only after the rename back from flang-new that seems to be scheduled for llvm20, maybe the Windows options including current CMake specials should simply be added to the documentation ?