Add (gmake) support for LLVM17's new flang

[martin-frbg]

No description provided.

[ningli-amd]

Hi @martin-frbg . This PR was merged eight months ago. But may I ask you to revisit the implementation details?

I am experimenting with AOCC, which is an LLVM based compiler and continues to use the Classic Flang and has its Fortran driver called flang. Your addition to f_check in this PR detects flang based on its major version. This logic will break if AOCC (or any other LLVM-based Fortran compiler that isn't flang-new) moves to LLVM 17 or greater. In this scenario, AOCC will be identified as having a FLANGNEW vendor string, resulting in the wrong calling convention being set in Makefile.system. This will break some Fortran based test codes in make tests, such as test/cblat1.

This problem will be exaggerated as the Spack recipe of OpenBLAS invokes make tests by default.

Can you please give this a second thought? Thanks.

[martin-frbg]

umm, I know the current method is awfully fragile, but if your compiler only self-identifies as LLVM flang 17 without being same then I think you are asking for trouble. If it still puts "F90 Flang" as an info string in the .s file it generates, or if it still uses "AMD clang" in its version string I can check for those - grabbing the compiler name and version number is mainly a kludge for those who put only some variation of "GNU" or "GCC" in the intermediate assembler output

[ningli-amd]

Thanks for looking into this. AOCC does identify itself with a reasonable output in a consistent format:

# for an very old AOCC 3.2
[user1@test ~]$ flang -v
AMD clang version 13.0.0 (CLANG: AOCC_3.2.0-Build#128 2021_11_12) (based on LLVM Mirror.Version.13.0.0)
# for the latest AOCC 4.2
[user1@test ~]$ flang -v
AMD clang version 16.0.3 (CLANG: AOCC_4.2.0-Build#89 2023_12_13)

And I assume future versions will print something in the same format. Does this contain enough information for you to work for a better detection mechanism?