On Fri Sep 29 11:33:53 2023 +0000, Jacek Caban wrote:
I was wondering about how those macros should work. AFAICT there is no `__arm64ec__` macro on MSVC, it was invented recently in clang by @bylaws: https://github.com/llvm/llvm-project/pull/65420. From compiler's perspective defining macros like `__aarch64__` makes sense, because it's a standard everywhere outside MSVC. However, there is nothing to be compatible with in case of ARM64EC. In practice, this means that there will be an extra unneeded difference between mingw and MSVC. I'm tempted to suggest removing `__arm64ec__` from clang before backward compatibility is an issue, but I'm not sure about that so opinions are welcomed.
I also generally dislike unnecessary differences between mingw and MSVC environments, but this one is quite clear IMO; in mingw mode, the compiler shouldn't predefine any `_M_<arch>` defines, but it should do that in the `__<arch>__` namespace. But here there's indeed no predecent for what to name it, so we do need one. And `__aarch64ec__` isn't better, since there's literally no such thing as `aarch64ec`.
@julliard So yes, there is an `__arm64ec__` define that we could check for, in mingw contexts. (For MSVC contexts, I guess we should define that based on `_M_ARM64EC`, if that's what's done for other architecture macros? Or does Wine carry parallel checks for GNU and MSVC style arch macros everywhere throughout?)