On Mon Jan 27 13:08:13 2025 +0000, Jinoh Kang wrote:
Admittedly my terminology was befuddled, but I believe I wasn't intentionally "mixing things up." MinGW(-w64) demands constructs like `__MINGW32__`, `__attribute__((ms_struct))`, and the Itanium C++ ABI (for x86_64) from the compiler. Initially only GCC supported them, and then Clang had to follow suit by matching GCC's semantics. LLVM eventually had to gain two separate modes (MinGW and MSVC) just for Windows PE target because MinGW has its own set of "C(++) extensions" incompatible with MSVC (which defines `_MSC_VER` instead, has ms struct semantics by default, and has its own C++ ABI). On ARM64, the role is reversed: LLVM got to decide first what the aforementioned MinGW constructs mean on Windows ARM. Now, if GCC is to ever support ARM64, it has to be compatible with whatever semantics Clang has already decided along while GCC's support was "lagging behind." IMO it doesn't make sense for MinGW to distinguish between "GCC MinGW mode" and "Clang MinGW mode." The former has to emulate the later. In that sense, MinGW (while ostensibly being just "headers and libraries") actually introduces a lot of stuff into the toolchain landscape like the choice of C++ ABI (incompatible with MSVC) as well as its own set of macros and extensions. This is what I meant by "MinGW going its own way with Clang, without GCC counterpart."
Feel free to correct me though; in any case I'm not an active contributor to MSYS2/MinGW and it's very possible that I got details completely wrong. I just wanted to clarify what was arguably initially vague from my side. In any case, thanks for your patience.
(Please excuse me if my replies are late; I'm currently on vacation and my timezone GMT+9 is quite distant from some other Wine contributors.)