On Fri Sep 29 11:55:06 2023 +0000, Martin Storsjö wrote:
Thanks - I just found the same when checking around. However for the PE/ELF split, we only execute that check for the ELF side host compiler, it seems. When compiling with clang in MSVC mode, we never execute that check. (Perhaps we should?) However, even in MSVC mode, Clang does define `__aarch64__`, in addition to `_M_ARM64`. So perhaps we should do the same for `__arm64ec__` as well? Or perhaps that's already done by the commit by @bylaws - I think that's done based on my reading of that commit, but I haven't tested it out myself. So I guess that just leaves the case of compiling with actual MSVC (which I believe is kinda relevant now, given the current incomplete arm64ec support in LLVM/Clang). I guess we could/should extend the `WINE_CHECK_DEFINE` handling for the PE compiler as well, and consistently use the GNU style naming? But I guess that requires knowing more about arm64ec in configure, which we don't do right now (but I presume we'll need sooner or later anyway)?
I wasn't plan using the actual MSVC with Wine build system myself, but yes, in theory we could support that and something like you suggest would be needed then.
And yes, `__arm64ec__` is already defined in addition to `_M_ARM64EC` by clang for MSVC targets.
BTW, I always considered handling of `_M_<arch>` macros in mingw to be a hack working around GCC shortcomings. They are defined in a header, so they work only if you include any crt headers first, which is not what one could expect. I recall hitting it while porting code to mingw. While it's too late for other platforms, I just feel like we could do better for new ones. I find explicitly skipping `_M_<arch>` macro in clang for mingw targets only to define it in a less reliable way in mingw headers to be sub-optimal.