[flang] Implement MSVC predefined macros for Windows

[pbo-linaro]

Linaro has been working on flang support, for Windows on Arm. It is included in official release for this platform.
The version included targets MSVC ABI, and not GNU one (available with msys2).

We have been trying to build OpenBLAS and ran into issues with CMake support.
Currently, we are working with CMake community to support flang (MSVC), see this pull request.

As part of the feedback from CMake maintainer, it is currently difficult to identify which ABI and architecture flang is targeting. One solution, as suggested here, would be to implement a set of MSVC predefined macros, like clang already does.
At least having _MSC_VER and _M_{X64,ARM64,IX86}, would be a good start. It would allow CMake, or any other tool, to identify easily flang configuration, without having to parse any output result.

[bradking]

Cc: @DavidTruby

[llvmbot]

@llvm/issue-subscribers-flang-driver

Author: Pierrick Bouvier (pbo-linaro)

Linaro has been working on flang support, for Windows on Arm. It is included in [official release](https://github.com/llvm/llvm-project/releases/download/llvmorg-17.0.1/LLVM-17.0.1-woa64.exe) for this platform. The version included targets MSVC ABI, and not GNU one (available with msys2).

We have been trying to build OpenBLAS and ran into issues with CMake support.
Currently, we are working with CMake community to support flang (MSVC), see this pull request.

As part of the feedback from CMake maintainer, it is currently difficult to identify which ABI and architecture flang is targeting. One solution, as suggested here, would be to implement a set of MSVC predefined macros, like clang already does.
At least having _MSC_VER and _M_{X64,ARM64,IX86}, would be a good start. It would allow CMake, or any other tool, to identify easily flang configuration, without having to parse any output result.

[DavidTruby]

I think adding these macros makes sense, I’m happy to post a patch to add them. #72519 also contains the macros used to check the msvc crt being used, I’ll put MSC_VER and the target macros in a separate patch

[DavidTruby]

Having had another look, I'm not sure MSC_VER really means much for flang; I'm happy that we can define it to whatever the default is but we aren't passing C or C++ stdlib types across any sort of ABI boundary so I'm not sure it matters which ABI version you're building for? Correct me if I'm wrong here and there's something I've missed.

If I'm correct about the above, we can define it to whatever clang uses as a default so you can check if you are targeting the MSVC ABI or not but I don't want to add support for the -fms-compatibility-version flag because I don't think we should suggest that it does anything when it doesn't.

[bradking]

I think defining _MSC_VER to clang's default is fine. If anyone later has a use case that needs a more accurate value, -fms-compatibility-version can be reconsidered later.

[bradking]

Actually while testing #73250 I found that you're actually defining a precise _MSC_VER value. It can even be controlled by flang-new -target x86_64-pc-windows-msvc19.35.