Hi Richard,
Thank you for your review!
The MS_ABI definition is for the x86/x64 MS ABI, and it's clear that it
shouldn't be used on aarch64.
The AARCH64_CALLING_ABI_MS definition resolves the issue.
It just needs to be properly handled in mingw32.h.
The change below is sufficient to resolve the ABI usage in mingw.
Regards,
Evgeny
gcc/config.gcc
- tm_defines="${tm_defines} TARGET_ARM64_MS_ABI=1"
+ tm_defines="${tm_defines} TARGET_AARCH64_MS_ABI=1"
config/aarch64/aarch64-opts.h
+/* Available call ABIs. */
+enum aarch64_calling_abi
+{
+ AARCH64_CALLING_ABI_EABI,
+ AARCH64_CALLING_ABI_MS
+};
+
gcc/config/mingw/mingw32.h
@@ -19,7 +19,11 @@
-#define DEFAULT_ABI MS_ABI
+#if defined (TARGET_AARCH64_MS_ABI)
+# define DEFAULT_ABI AARCH64_CALLING_ABI_MS
+#else
+# define DEFAULT_ABI MS_ABI
+#endif
-----Original Message-----
Friday, February 23, 2024 6:50 PM
Richard Sandiford wrote:
> What do you think about this change for v2?
>
> +/* Available call ABIs. */
> +enum aarch64_calling_abi
> +{
> + AARCH64_CALLING_ABI_EABI,
> + AARCH64_CALLING_ABI_MS,
> + MS_ABI = AARCH64_CALLING_ABI_MS
> +};
> +
How is MS_ABI used in practice? When I apply locally, it looks like the two
non-x86 uses are in:
gcc/config/mingw/mingw32.h: if (TARGET_64BIT && ix86_abi == MS_ABI)
\
gcc/config/mingw/winnt-d.cc: if (TARGET_64BIT && ix86_abi == MS_ABI)
But these should fail to build if used, because AFAICT there's no definition of
ix86_abi on aarch64.
The first match is in EXTRA_OS_CPP_BUILTINS, but I couldn't see any uses of
that in aarch64 code, which would explain why everything builds OK.
The winnt-d.cc occurence looks like it would break the build with the D
frontend enabled though.
Are there two distinct ABIs for aarch64-*-mingw*? Or are these distinctions
ignored on aarch64 and just retained for compatibility?
If there are two distinct ABIs then we should probably add them to
aarch64_arm_pcs. But if there is only a single ABI, we should probably avoid
adding calling_abi altogether and instead provide a macro like TARGET_IS_MS_ABI
that aarch64 and x86 can define differently.
(To be clear, I don't think the different handling of x18 matters for the PCS
classification. That's an orthogonal platform property that applies to all PCS
variants equally. No-one had suggested otherwise, just wanted to say in case.
:-) )
Thanks,
Richard
