[PATCH v1 00/13] Add aarch64-w64-mingw32 target

[PATCH v1 00/13] Add aarch64-w64-mingw32 target

[Evgeny Karpov]

Hello,

We would like to take your attention to the review of changes for the
new GCC target, aarch64-w64-mingw32. The new target will be
supported, tested, added to CI, and maintained by Linaro. This marks
the first of three planned patch series contributing to the GCC C
compiler's support for Windows Arm64.

1. Minimal aarch64-w64-mingw32 C implementation to cross-compile
hello-world with libgcc for Windows Arm64 using MinGW.
2. Extension of the aarch64-w64-mingw32 C implementation to
cross-compile OpenSSL, OpenBLAS, FFmpeg, and libjpeg-turbo. All
packages successfully pass tests.
3. Addition of call stack support for debugging, resolution of
optimization issues in the C compiler, and DLL export/import for the
aarch64-w64-mingw32 target.

This patch series introduces the 1st point, which involves building
hello-world for the aarch64-w64-mingw32 target. The patch depends on
the binutils changes for the aarch64-w64-mingw32 target that have
already been merged.

The binutils should include recent relocation fixes.
f87eaf8ff3995a5888c6dc4996a20c770e6bcd36
aarch64: Add new relocations and limit COFF AArch64 relocation offsets

The series is structured in a way to trivially show that it should not
affect any other targets.

In this patch, several changes have been made to support the
aarch64-w64-mingw32 target for GCC. The modifications include the
definition of the MS ABI for aarch64, adjustments to FIXED_REGISTERS
and STATIC_CHAIN_REGNUM for different ABIs, and specific definitions
for COFF format on AArch64. Additionally, the patch reuses MinGW
<stdint.h> types and definitions from i386, relocating them to a new
mingw folder for shared usage between both targets.

MinGW-specific options have been introduced for AArch64, along with
override options for aarch64-w64-mingw32. Builtin stack probing for
override options for aarch64-w64-mingw32. Builtin stack probing for
AArch64 has been enabled as an alternative for chkstk. Symbol name
encoding and section information handling for aarch64-w64-mingw32 have
been incorporated, and the MinGW environment has been added, which
will also be utilized for defining the Cygwin environment in the
future.

The patch includes renaming "x86 Windows Options" to "Cygwin and MinGW
Options," which now encompasses AArch64 as well. AArch64-specific
Cygwin and MinGW Options have been introduced for the unique
requirements of the AArch64 architecture.

Function type declaration and named sections support have been added.
The necessary objects for Cygwin and MinGW have been built for the
aarch64-w64-mingw32 target, and relevant files such as msformat-c.cc
and winnt-d.cc have been moved to the mingw folder for reuse in
AArch64.

Furthermore, the aarch64-w64-mingw32 target has been included in both
libatomic and libgcc, ensuring support for the AArch64 architecture
within these libraries. These changes collectively enhance the
capabilities of GCC for the specified target.

Coauthors: Zac Walker <zacwalker@microsoft.com>,
Mark Harmstone <mark@harmstone.com>  and
Ron Riddle <ron.riddle@microsoft.com>

Refactored, prepared, and validated by 
Radek Barton <radek.barton@microsoft.com> and 
Evgeny Karpov <evgeny.karpov@microsoft.com>

Special thanks to the Linaro GNU toolchain team for internal review
and assistance in preparing the patch series!

Regards,
Evgeny


Zac Walker (13):
  Introduce aarch64-w64-mingw32 target
  aarch64: The aarch64-w64-mingw32 target implements the MS ABI
  aarch64: Mark x18 register as a fixed register for MS ABI
  aarch64: Add aarch64-w64-mingw32 COFF
  Reuse MinGW from i386 for AArch64
  Rename section and encoding functions from i386 which will be used in
    aarch64
  Exclude i386 functionality from aarch64 build
  aarch64: Add Cygwin and MinGW environments for AArch64
  aarch64: Add SEH to machine_function
  Rename "x86 Windows Options" to "Cygwin and MinGW Options"
  aarch64: Build and add objects for Cygwin and MinGW for AArch64
  aarch64: Add aarch64-w64-mingw32 target to libatomic
  Add aarch64-w64-mingw32 target to libgcc

 fixincludes/mkfixinc.sh                       |   3 +-
 gcc/config.gcc                                |  47 +++--
 gcc/config/aarch64/aarch64-coff.h             |  92 +++++++++
 gcc/config/aarch64/aarch64-opts.h             |   7 +
 gcc/config/aarch64/aarch64-protos.h           |   5 +
 gcc/config/aarch64/aarch64.h                  |  25 ++-
 gcc/config/aarch64/cygming.h                  | 178 ++++++++++++++++++
 gcc/config/i386/cygming.h                     |  18 +-
 gcc/config/i386/cygming.opt.urls              |  30 ---
 gcc/config/i386/i386-protos.h                 |  12 +-
 gcc/config/i386/mingw-w64.opt.urls            |   2 +-
 gcc/config/lynx.opt.urls                      |   2 +-
 gcc/config/{i386 => mingw}/cygming.opt        |   0
 gcc/config/mingw/cygming.opt.urls             |  30 +++
 gcc/config/{i386 => mingw}/cygwin-d.cc        |   0
 gcc/config/{i386 => mingw}/mingw-stdint.h     |   0
 gcc/config/{i386 => mingw}/mingw.opt          |   0
 gcc/config/{i386 => mingw}/mingw.opt.urls     |   2 +-
 gcc/config/{i386 => mingw}/mingw32.h          |   0
 gcc/config/{i386 => mingw}/msformat-c.cc      |   0
 gcc/config/{i386 => mingw}/t-cygming          |  23 ++-
 gcc/config/{i386 => mingw}/winnt-cxx.cc       |   0
 gcc/config/{i386 => mingw}/winnt-d.cc         |   0
 gcc/config/{i386 => mingw}/winnt-stubs.cc     |   0
 gcc/config/{i386 => mingw}/winnt.cc           |  30 +--
 gcc/doc/invoke.texi                           |  12 +-
 gcc/varasm.cc                                 |   2 +-
 libatomic/configure.tgt                       |   2 +-
 libgcc/config.host                            |  23 ++-
 libgcc/config/aarch64/t-no-eh                 |   2 +
 libgcc/config/{i386 => mingw}/t-gthr-win32    |   0
 libgcc/config/{i386 => mingw}/t-mingw-pthread |   0
 32 files changed, 450 insertions(+), 97 deletions(-)
 create mode 100644 gcc/config/aarch64/aarch64-coff.h
 create mode 100644 gcc/config/aarch64/cygming.h
 delete mode 100644 gcc/config/i386/cygming.opt.urls
 rename gcc/config/{i386 => mingw}/cygming.opt (100%)
 create mode 100644 gcc/config/mingw/cygming.opt.urls
 rename gcc/config/{i386 => mingw}/cygwin-d.cc (100%)
 rename gcc/config/{i386 => mingw}/mingw-stdint.h (100%)
 rename gcc/config/{i386 => mingw}/mingw.opt (100%)
 rename gcc/config/{i386 => mingw}/mingw.opt.urls (86%)
 rename gcc/config/{i386 => mingw}/mingw32.h (100%)
 rename gcc/config/{i386 => mingw}/msformat-c.cc (100%)
 rename gcc/config/{i386 => mingw}/t-cygming (73%)
 rename gcc/config/{i386 => mingw}/winnt-cxx.cc (100%)
 rename gcc/config/{i386 => mingw}/winnt-d.cc (100%)
 rename gcc/config/{i386 => mingw}/winnt-stubs.cc (100%)
 rename gcc/config/{i386 => mingw}/winnt.cc (97%)
 create mode 100644 libgcc/config/aarch64/t-no-eh
 rename libgcc/config/{i386 => mingw}/t-gthr-win32 (100%)
 rename libgcc/config/{i386 => mingw}/t-mingw-pthread (100%)

-- 
2.25.1

[PATCH v1 01/13] Introduce aarch64-w64-mingw32 target

[Evgeny Karpov]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: v1-0001-Introduce-aarch64-w64-mingw32-target.txt --]
[-- Type: text/plain, Size: 1732 bytes --]

From c5fec28077184119bc81d927e6062704c1796446 Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Tue, 30 Jan 2024 06:42:46 +0100
Subject: [PATCH v1 01/13] Introduce aarch64-w64-mingw32 target

Add the initial aarch64-w64-mingw32 target for gcc.

fixincludes/ChangeLog:

	* mkfixinc.sh: Extend for *-mingw32* targets.

gcc/ChangeLog:

	* config.gcc: Add aarch64-w64-mingw32 target.
---
 fixincludes/mkfixinc.sh |  3 +--
 gcc/config.gcc          | 14 ++++++++++++++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/fixincludes/mkfixinc.sh b/fixincludes/mkfixinc.sh
index df90720b716..7112f4dcd64 100755
--- a/fixincludes/mkfixinc.sh
+++ b/fixincludes/mkfixinc.sh
@@ -12,8 +12,7 @@ target=fixinc.sh
 # Check for special fix rules for particular targets
 case $machine in
     i?86-*-cygwin* | \
-    i?86-*-mingw32* | \
-    x86_64-*-mingw32* | \
+    *-mingw32* | \
     powerpc-*-eabisim* | \
     powerpc-*-eabi*    | \
     powerpc-*-rtems*   | \
diff --git a/gcc/config.gcc b/gcc/config.gcc
index a0f9c672308..092a091595d 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1263,6 +1263,20 @@ aarch64*-*-linux*)
 	done
 	TM_MULTILIB_CONFIG=`echo $TM_MULTILIB_CONFIG | sed 's/^,//'`
 	;;
+aarch64*-*-mingw*)
+	tmake_file="${tmake_file} aarch64/t-aarch64"
+	case ${enable_threads} in
+	  "" | yes | win32)
+	    thread_file='win32'
+	    ;;
+	  posix)
+	    thread_file='posix'
+	    ;;
+	esac
+	default_use_cxa_atexit=yes
+	need_64bit_isa=yes
+	user_headers_inc_next_post="${user_headers_inc_next_post} float.h"
+	;;
 aarch64*-wrs-vxworks*)
         tm_file="${tm_file} elfos.h aarch64/aarch64-elf.h"
         tm_file="${tm_file} vx-common.h vxworks.h aarch64/aarch64-vxworks.h"
-- 
2.25.1

Re: [PATCH v1 01/13] Introduce aarch64-w64-mingw32 target

[Andrew Pinski]

On Wed, Feb 21, 2024 at 10:17 AM Evgeny Karpov
<Evgeny.Karpov@microsoft.com> wrote:
>
>

> need_64bit_isa=yes

This is not needed in the patch as it is only used for x86_64 targets.

Should you make sure nobody specifies the big-endian target:
aarch64_be-w64-mingw32  ?

Thanks,
Andrew Pinski

Re: [PATCH v1 00/13] Add aarch64-w64-mingw32 target

[Maxim Kuvyrkov]

Hi Evgeny,

Great job!

For reference, here is a test build of this patch series using Linaro Toolchain CI: https://ci.linaro.org/view/tcwg-build/job/tcwg_gnu_mingw_build--master-woa64-build/9/artifact/artifacts/ 

--
Maxim Kuvyrkov
https://www.linaro.org

> On Feb 21, 2024, at 21:47, Evgeny Karpov <Evgeny.Karpov@microsoft.com> wrote:
> 
> Hello,
> 
> We would like to take your attention to the review of changes for the
> new GCC target, aarch64-w64-mingw32. The new target will be
> supported, tested, added to CI, and maintained by Linaro. This marks
> the first of three planned patch series contributing to the GCC C
> compiler's support for Windows Arm64.
> 
> 1. Minimal aarch64-w64-mingw32 C implementation to cross-compile
> hello-world with libgcc for Windows Arm64 using MinGW.
> 2. Extension of the aarch64-w64-mingw32 C implementation to
> cross-compile OpenSSL, OpenBLAS, FFmpeg, and libjpeg-turbo. All
> packages successfully pass tests.
> 3. Addition of call stack support for debugging, resolution of
> optimization issues in the C compiler, and DLL export/import for the
> aarch64-w64-mingw32 target.
> 
> This patch series introduces the 1st point, which involves building
> hello-world for the aarch64-w64-mingw32 target. The patch depends on
> the binutils changes for the aarch64-w64-mingw32 target that have
> already been merged.
> 
> The binutils should include recent relocation fixes.
> f87eaf8ff3995a5888c6dc4996a20c770e6bcd36
> aarch64: Add new relocations and limit COFF AArch64 relocation offsets
> 
> The series is structured in a way to trivially show that it should not
> affect any other targets.
> 
> In this patch, several changes have been made to support the
> aarch64-w64-mingw32 target for GCC. The modifications include the
> definition of the MS ABI for aarch64, adjustments to FIXED_REGISTERS
> and STATIC_CHAIN_REGNUM for different ABIs, and specific definitions
> for COFF format on AArch64. Additionally, the patch reuses MinGW
> <stdint.h> types and definitions from i386, relocating them to a new
> mingw folder for shared usage between both targets.
> 
> MinGW-specific options have been introduced for AArch64, along with
> override options for aarch64-w64-mingw32. Builtin stack probing for
> override options for aarch64-w64-mingw32. Builtin stack probing for
> AArch64 has been enabled as an alternative for chkstk. Symbol name
> encoding and section information handling for aarch64-w64-mingw32 have
> been incorporated, and the MinGW environment has been added, which
> will also be utilized for defining the Cygwin environment in the
> future.
> 
> The patch includes renaming "x86 Windows Options" to "Cygwin and MinGW
> Options," which now encompasses AArch64 as well. AArch64-specific
> Cygwin and MinGW Options have been introduced for the unique
> requirements of the AArch64 architecture.
> 
> Function type declaration and named sections support have been added.
> The necessary objects for Cygwin and MinGW have been built for the
> aarch64-w64-mingw32 target, and relevant files such as msformat-c.cc
> and winnt-d.cc have been moved to the mingw folder for reuse in
> AArch64.
> 
> Furthermore, the aarch64-w64-mingw32 target has been included in both
> libatomic and libgcc, ensuring support for the AArch64 architecture
> within these libraries. These changes collectively enhance the
> capabilities of GCC for the specified target.
> 
> Coauthors: Zac Walker <zacwalker@microsoft.com>,
> Mark Harmstone <mark@harmstone.com>  and
> Ron Riddle <ron.riddle@microsoft.com>
> 
> Refactored, prepared, and validated by 
> Radek Barton <radek.barton@microsoft.com> and 
> Evgeny Karpov <evgeny.karpov@microsoft.com>
> 
> Special thanks to the Linaro GNU toolchain team for internal review
> and assistance in preparing the patch series!
> 
> Regards,
> Evgeny
> 
> 
> Zac Walker (13):
>  Introduce aarch64-w64-mingw32 target
>  aarch64: The aarch64-w64-mingw32 target implements the MS ABI
>  aarch64: Mark x18 register as a fixed register for MS ABI
>  aarch64: Add aarch64-w64-mingw32 COFF
>  Reuse MinGW from i386 for AArch64
>  Rename section and encoding functions from i386 which will be used in
>    aarch64
>  Exclude i386 functionality from aarch64 build
>  aarch64: Add Cygwin and MinGW environments for AArch64
>  aarch64: Add SEH to machine_function
>  Rename "x86 Windows Options" to "Cygwin and MinGW Options"
>  aarch64: Build and add objects for Cygwin and MinGW for AArch64
>  aarch64: Add aarch64-w64-mingw32 target to libatomic
>  Add aarch64-w64-mingw32 target to libgcc
> 
> fixincludes/mkfixinc.sh                       |   3 +-
> gcc/config.gcc                                |  47 +++--
> gcc/config/aarch64/aarch64-coff.h             |  92 +++++++++
> gcc/config/aarch64/aarch64-opts.h             |   7 +
> gcc/config/aarch64/aarch64-protos.h           |   5 +
> gcc/config/aarch64/aarch64.h                  |  25 ++-
> gcc/config/aarch64/cygming.h                  | 178 ++++++++++++++++++
> gcc/config/i386/cygming.h                     |  18 +-
> gcc/config/i386/cygming.opt.urls              |  30 ---
> gcc/config/i386/i386-protos.h                 |  12 +-
> gcc/config/i386/mingw-w64.opt.urls            |   2 +-
> gcc/config/lynx.opt.urls                      |   2 +-
> gcc/config/{i386 => mingw}/cygming.opt        |   0
> gcc/config/mingw/cygming.opt.urls             |  30 +++
> gcc/config/{i386 => mingw}/cygwin-d.cc        |   0
> gcc/config/{i386 => mingw}/mingw-stdint.h     |   0
> gcc/config/{i386 => mingw}/mingw.opt          |   0
> gcc/config/{i386 => mingw}/mingw.opt.urls     |   2 +-
> gcc/config/{i386 => mingw}/mingw32.h          |   0
> gcc/config/{i386 => mingw}/msformat-c.cc      |   0
> gcc/config/{i386 => mingw}/t-cygming          |  23 ++-
> gcc/config/{i386 => mingw}/winnt-cxx.cc       |   0
> gcc/config/{i386 => mingw}/winnt-d.cc         |   0
> gcc/config/{i386 => mingw}/winnt-stubs.cc     |   0
> gcc/config/{i386 => mingw}/winnt.cc           |  30 +--
> gcc/doc/invoke.texi                           |  12 +-
> gcc/varasm.cc                                 |   2 +-
> libatomic/configure.tgt                       |   2 +-
> libgcc/config.host                            |  23 ++-
> libgcc/config/aarch64/t-no-eh                 |   2 +
> libgcc/config/{i386 => mingw}/t-gthr-win32    |   0
> libgcc/config/{i386 => mingw}/t-mingw-pthread |   0
> 32 files changed, 450 insertions(+), 97 deletions(-)
> create mode 100644 gcc/config/aarch64/aarch64-coff.h
> create mode 100644 gcc/config/aarch64/cygming.h
> delete mode 100644 gcc/config/i386/cygming.opt.urls
> rename gcc/config/{i386 => mingw}/cygming.opt (100%)
> create mode 100644 gcc/config/mingw/cygming.opt.urls
> rename gcc/config/{i386 => mingw}/cygwin-d.cc (100%)
> rename gcc/config/{i386 => mingw}/mingw-stdint.h (100%)
> rename gcc/config/{i386 => mingw}/mingw.opt (100%)
> rename gcc/config/{i386 => mingw}/mingw.opt.urls (86%)
> rename gcc/config/{i386 => mingw}/mingw32.h (100%)
> rename gcc/config/{i386 => mingw}/msformat-c.cc (100%)
> rename gcc/config/{i386 => mingw}/t-cygming (73%)
> rename gcc/config/{i386 => mingw}/winnt-cxx.cc (100%)
> rename gcc/config/{i386 => mingw}/winnt-d.cc (100%)
> rename gcc/config/{i386 => mingw}/winnt-stubs.cc (100%)
> rename gcc/config/{i386 => mingw}/winnt.cc (97%)
> create mode 100644 libgcc/config/aarch64/t-no-eh
> rename libgcc/config/{i386 => mingw}/t-gthr-win32 (100%)
> rename libgcc/config/{i386 => mingw}/t-mingw-pthread (100%)
> 
> -- 
> 2.25.1
> 

[PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements

[Evgeny Karpov]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: v1-0002-aarch64-The-aarch64-w64-mingw32-target-implements.txt --]
[-- Type: text/plain, Size: 873 bytes --]

From 5cab07f01f66ba162b7d542e1a61c96f49942331 Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Tue, 20 Feb 2024 15:32:08 +0100
Subject: [PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements
 the MS ABI

Two ABIs for aarch64 have been defined for different platforms.

gcc/ChangeLog:

	* config/aarch64/aarch64-opts.h (enum calling_abi): Define
	two ABIs.
---
 gcc/config/aarch64/aarch64-opts.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/gcc/config/aarch64/aarch64-opts.h b/gcc/config/aarch64/aarch64-opts.h
index a05c0d3ded1..77e3eae9595 100644
--- a/gcc/config/aarch64/aarch64-opts.h
+++ b/gcc/config/aarch64/aarch64-opts.h
@@ -131,4 +131,11 @@ enum aarch64_early_ra_scope {
   AARCH64_EARLY_RA_NONE
 };
 
+/* Available call ABIs.  */
+enum calling_abi
+{
+  AARCH64_EABI = 0,
+  MS_ABI = 1
+};
+
 #endif
-- 
2.25.1

[PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

[Evgeny Karpov]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: v1-0003-aarch64-Mark-x18-register-as-a-fixed-register-for.txt --]
[-- Type: text/plain, Size: 3204 bytes --]

From 72ca3f49e3eef9b18946b8d4e77019c1441e1a97 Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Tue, 20 Feb 2024 15:30:33 +0100
Subject: [PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for
 MS ABI

Define the MS ABI for aarch64-w64-mingw32.
Adjust FIXED_REGISTERS and STATIC_CHAIN_REGNUM for different ABIs.
The X18 register is reserved on Windows for the TEB.

gcc/ChangeLog:

	* config.gcc: Define TARGET_ARM64_MS_ABI when Arm64 MS ABI is
	used.
	* config/aarch64/aarch64.h (FIXED_X18): Define if X18
	regsiter is fixed.
	(CALL_USED_X18): Define if X18 register is call used.
	(FIXED_REGISTERS): Adjust FIXED_REGISTERS for different ABIs.
	(STATIC_CHAIN_REGNUM): Define STATIC_CHAIN_REGNUM acording to
	ABI.
---
 gcc/config.gcc               |  1 +
 gcc/config/aarch64/aarch64.h | 19 ++++++++++++++++---
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 092a091595d..2a9e4c44f50 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1276,6 +1276,7 @@ aarch64*-*-mingw*)
 	default_use_cxa_atexit=yes
 	need_64bit_isa=yes
 	user_headers_inc_next_post="${user_headers_inc_next_post} float.h"
+	tm_defines="${tm_defines} TARGET_ARM64_MS_ABI=1"
 	;;
 aarch64*-wrs-vxworks*)
         tm_file="${tm_file} elfos.h aarch64/aarch64-elf.h"
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 45e901cda64..36916e7a97d 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -536,11 +536,20 @@ constexpr auto AARCH64_FL_DEFAULT_ISA_MODE = AARCH64_FL_SM_OFF;
    register.  GCC internally uses the poly_int variable aarch64_sve_vg
    instead.  */
 
+/* X18 reserved for the TEB on Windows.  */
+#ifdef TARGET_ARM64_MS_ABI
+# define FIXED_X18 1
+# define CALL_USED_X18 0
+#else
+# define FIXED_X18 0
+# define CALL_USED_X18 1
+#endif
+
 #define FIXED_REGISTERS					\
   {							\
     0, 0, 0, 0,   0, 0, 0, 0,	/* R0 - R7 */		\
     0, 0, 0, 0,   0, 0, 0, 0,	/* R8 - R15 */		\
-    0, 0, 0, 0,   0, 0, 0, 0,	/* R16 - R23 */		\
+    0, 0, FIXED_X18, 0,   0, 0, 0, 0,	/* R16 - R23.  */	\
     0, 0, 0, 0,   0, 1, 0, 1,	/* R24 - R30, SP */	\
     0, 0, 0, 0,   0, 0, 0, 0,   /* V0 - V7 */           \
     0, 0, 0, 0,   0, 0, 0, 0,   /* V8 - V15 */		\
@@ -564,7 +573,7 @@ constexpr auto AARCH64_FL_DEFAULT_ISA_MODE = AARCH64_FL_SM_OFF;
   {							\
     1, 1, 1, 1,   1, 1, 1, 1,	/* R0 - R7 */		\
     1, 1, 1, 1,   1, 1, 1, 1,	/* R8 - R15 */		\
-    1, 1, 1, 0,   0, 0, 0, 0,	/* R16 - R23 */		\
+    1, 1, CALL_USED_X18, 0, 0,   0, 0, 0, /* R16 - R23.  */   \
     0, 0, 0, 0,   0, 1, 1, 1,	/* R24 - R30, SP */	\
     1, 1, 1, 1,   1, 1, 1, 1,	/* V0 - V7 */		\
     0, 0, 0, 0,   0, 0, 0, 0,	/* V8 - V15 */		\
@@ -642,7 +651,11 @@ constexpr auto AARCH64_FL_DEFAULT_ISA_MODE = AARCH64_FL_SM_OFF;
    uses alloca.  */
 #define EXIT_IGNORE_STACK	(cfun->calls_alloca)
 
-#define STATIC_CHAIN_REGNUM		R18_REGNUM
+#ifdef TARGET_ARM64_MS_ABI
+# define STATIC_CHAIN_REGNUM		R17_REGNUM
+#else
+# define STATIC_CHAIN_REGNUM		R18_REGNUM
+#endif
 #define HARD_FRAME_POINTER_REGNUM	R29_REGNUM
 #define FRAME_POINTER_REGNUM		SFP_REGNUM
 #define STACK_POINTER_REGNUM		SP_REGNUM
-- 
2.25.1

[PATCH v1 04/13] aarch64: Add aarch64-w64-mingw32 COFF

[Evgeny Karpov]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: v1-0004-aarch64-Add-aarch64-w64-mingw32-COFF.txt --]
[-- Type: text/plain, Size: 4236 bytes --]

From 55fd2a63afa9abb3543d714b6f5925efd2682e08 Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Wed, 21 Feb 2024 12:20:46 +0100
Subject: [PATCH v1 04/13] aarch64: Add aarch64-w64-mingw32 COFF

Define ASM specific for COFF format on AArch64.

gcc/ChangeLog:

	* config.gcc: Add COFF format support definitions.
	* config/aarch64/aarch64-coff.h: New file.
---
 gcc/config.gcc                    |  1 +
 gcc/config/aarch64/aarch64-coff.h | 92 +++++++++++++++++++++++++++++++
 2 files changed, 93 insertions(+)
 create mode 100644 gcc/config/aarch64/aarch64-coff.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 2a9e4c44f50..34c7be72fb6 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1264,6 +1264,7 @@ aarch64*-*-linux*)
 	TM_MULTILIB_CONFIG=`echo $TM_MULTILIB_CONFIG | sed 's/^,//'`
 	;;
 aarch64*-*-mingw*)
+	tm_file="${tm_file} aarch64/aarch64-coff.h"
 	tmake_file="${tmake_file} aarch64/t-aarch64"
 	case ${enable_threads} in
 	  "" | yes | win32)
diff --git a/gcc/config/aarch64/aarch64-coff.h b/gcc/config/aarch64/aarch64-coff.h
new file mode 100644
index 00000000000..d91bc36b67b
--- /dev/null
+++ b/gcc/config/aarch64/aarch64-coff.h
@@ -0,0 +1,92 @@
+/* Machine description for AArch64 architecture.
+   Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   GCC is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   <http://www.gnu.org/licenses/>.  */
+
+#ifndef GCC_AARCH64_COFF_H
+#define GCC_AARCH64_COFF_H
+
+#include "aarch64.h"
+
+#ifndef LOCAL_LABEL_PREFIX
+# define LOCAL_LABEL_PREFIX 	""
+#endif
+
+/* Using long long breaks -ansi and -std=c90, so these will need to be
+   made conditional for an LLP64 ABI.  */
+#undef SIZE_TYPE
+#define SIZE_TYPE	"long long unsigned int"
+
+#undef PTRDIFF_TYPE
+#define PTRDIFF_TYPE	"long long int"
+
+#define TARGET_64BIT 1
+#undef LONG_TYPE_SIZE
+#define LONG_TYPE_SIZE 32
+
+#ifndef ASM_GENERATE_INTERNAL_LABEL
+# define ASM_GENERATE_INTERNAL_LABEL(STRING, PREFIX, NUM)  \
+  sprintf (STRING, "*%s%s%u", LOCAL_LABEL_PREFIX, PREFIX, (unsigned int)(NUM))
+#endif
+
+#define ASM_OUTPUT_ALIGN(STREAM, POWER)		\
+  fprintf (STREAM, "\t.align\t%d\n", (int)POWER)
+
+/* Output a common block.  */
+#ifndef ASM_OUTPUT_COMMON
+# define ASM_OUTPUT_COMMON(STREAM, NAME, SIZE, ROUNDED)	\
+    {							\
+      fprintf (STREAM, "\t.comm\t");			\
+      assemble_name (STREAM, NAME);			\
+      asm_fprintf (STREAM, ", %d, %d\n", 		\
+      (int)(ROUNDED), (int)(SIZE));	\
+    }
+#endif
+
+/* Output a local common block.  /bin/as can't do this, so hack a
+   `.space' into the bss segment.  Note that this is *bad* practice,
+   which is guaranteed NOT to work since it doesn't define STATIC
+   COMMON space but merely STATIC BSS space.  */
+#ifndef ASM_OUTPUT_ALIGNED_LOCAL
+# define ASM_OUTPUT_ALIGNED_LOCAL(STREAM, NAME, SIZE, ALIGN)		\
+    {									\
+      switch_to_section (bss_section);					\
+      ASM_OUTPUT_ALIGN (STREAM, floor_log2 (ALIGN / BITS_PER_UNIT));	\
+      ASM_OUTPUT_LABEL (STREAM, NAME);					\
+      fprintf (STREAM, "\t.space\t%d\n", (int)(SIZE));			\
+    }
+#endif
+
+#define ASM_OUTPUT_SKIP(STREAM, NBYTES) 	\
+  fprintf (STREAM, "\t.space\t%d  // skip\n", (int) (NBYTES))
+
+#define ASM_OUTPUT_TYPE_DIRECTIVE(STREAM, NAME, TYPE)
+#define ASM_DECLARE_FUNCTION_SIZE(FILE, FNAME, DECL)
+
+#define TEXT_SECTION_ASM_OP	"\t.text"
+#define DATA_SECTION_ASM_OP	"\t.data"
+#define BSS_SECTION_ASM_OP	"\t.bss"
+
+#define CTORS_SECTION_ASM_OP	"\t.section\t.ctors, \"aw\""
+#define DTORS_SECTION_ASM_OP	"\t.section\t.dtors, \"aw\""
+
+#define GLOBAL_ASM_OP "\t.global\t"
+
+#undef SUPPORTS_INIT_PRIORITY
+#define SUPPORTS_INIT_PRIORITY 0
+
+#endif
-- 
2.25.1

[PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[Evgeny Karpov]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: v1-0005-Reuse-MinGW-from-i386-for-AArch64.txt --]
[-- Type: text/plain, Size: 10826 bytes --]

From 408ca45f7c5c6e58208a7b8004f764dc0c1afdd3 Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Tue, 20 Feb 2024 18:15:27 +0100
Subject: [PATCH v1 05/13] Reuse MinGW from i386 for AArch64

This patch creates a new config/mingw directory to share MinGW
related definitions, and moves there the corresponding existing files
from config/i386. It also makes uses of them on the new
aarch64-w64-mingw32 target.

gcc/ChangeLog:

	* config.gcc: Adjust targets after moving MinGW related files
	from i386 to mingw folder.
	* config/i386/cygming.opt: Moved to...
	* config/mingw/cygming.opt: ...here.
	* config/i386/cygming.opt.urls: Moved to...
	* config/mingw/cygming.opt.urls: ...here.
	* config/i386/cygwin-d.cc: Moved to...
	* config/mingw/cygwin-d.cc: ...here.
	* config/i386/mingw-stdint.h: Moved to...
	* config/mingw/mingw-stdint.h: ...here.
	* config/i386/mingw.opt: Moved to...
	* config/mingw/mingw.opt: ...here.
	* config/i386/mingw.opt.urls: Moved to...
	* config/mingw/mingw.opt.urls: ...here.
	* config/i386/mingw32.h: Moved to...
	* config/mingw/mingw32.h: ...here.
	* config/i386/msformat-c.cc: Moved to...
	* config/mingw/msformat-c.cc: ...here.
	* config/i386/t-cygming: Moved to...
	* config/mingw/t-cygming: ...here and updated.
	* config/i386/winnt-cxx.cc: Moved to...
	* config/mingw/winnt-cxx.cc: ...here.
	* config/i386/winnt-d.cc: Moved to...
	* config/mingw/winnt-d.cc: ...here.
	* config/i386/winnt-stubs.cc: Moved to...
	* config/mingw/winnt-stubs.cc: ...here.
	* config/i386/winnt.cc: Moved to...
	* config/mingw/winnt.cc: ...here.
---
 gcc/config.gcc                              | 25 ++++++++++++---------
 gcc/config/{i386 => mingw}/cygming.opt      |  0
 gcc/config/{i386 => mingw}/cygming.opt.urls |  0
 gcc/config/{i386 => mingw}/cygwin-d.cc      |  0
 gcc/config/{i386 => mingw}/mingw-stdint.h   |  0
 gcc/config/{i386 => mingw}/mingw.opt        |  0
 gcc/config/{i386 => mingw}/mingw.opt.urls   |  0
 gcc/config/{i386 => mingw}/mingw32.h        |  0
 gcc/config/{i386 => mingw}/msformat-c.cc    |  0
 gcc/config/{i386 => mingw}/t-cygming        | 23 ++++++++++---------
 gcc/config/{i386 => mingw}/winnt-cxx.cc     |  0
 gcc/config/{i386 => mingw}/winnt-d.cc       |  0
 gcc/config/{i386 => mingw}/winnt-stubs.cc   |  0
 gcc/config/{i386 => mingw}/winnt.cc         |  0
 14 files changed, 27 insertions(+), 21 deletions(-)
 rename gcc/config/{i386 => mingw}/cygming.opt (100%)
 rename gcc/config/{i386 => mingw}/cygming.opt.urls (100%)
 rename gcc/config/{i386 => mingw}/cygwin-d.cc (100%)
 rename gcc/config/{i386 => mingw}/mingw-stdint.h (100%)
 rename gcc/config/{i386 => mingw}/mingw.opt (100%)
 rename gcc/config/{i386 => mingw}/mingw.opt.urls (100%)
 rename gcc/config/{i386 => mingw}/mingw32.h (100%)
 rename gcc/config/{i386 => mingw}/msformat-c.cc (100%)
 rename gcc/config/{i386 => mingw}/t-cygming (73%)
 rename gcc/config/{i386 => mingw}/winnt-cxx.cc (100%)
 rename gcc/config/{i386 => mingw}/winnt-d.cc (100%)
 rename gcc/config/{i386 => mingw}/winnt-stubs.cc (100%)
 rename gcc/config/{i386 => mingw}/winnt.cc (100%)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 34c7be72fb6..498ee702607 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1265,7 +1265,10 @@ aarch64*-*-linux*)
 	;;
 aarch64*-*-mingw*)
 	tm_file="${tm_file} aarch64/aarch64-coff.h"
+	tm_file="${tm_file} mingw/mingw32.h"
+	tm_file="${tm_file} mingw/mingw-stdint.h"
 	tmake_file="${tmake_file} aarch64/t-aarch64"
+	target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
 	case ${enable_threads} in
 	  "" | yes | win32)
 	    thread_file='win32'
@@ -2161,9 +2164,9 @@ i[4567]86-wrs-vxworks*|x86_64-wrs-vxworks7*)
 i[34567]86-*-cygwin*)
 	tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h i386/cygming.h i386/cygwin.h i386/cygwin-stdint.h"
 	xm_file=i386/xm-cygwin.h
-	tmake_file="${tmake_file} i386/t-cygming t-slibgcc"
-	target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc"
-	extra_options="${extra_options} i386/cygming.opt i386/cygwin.opt"
+	tmake_file="${tmake_file} mingw/t-cygming t-slibgcc"
+	target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
+	extra_options="${extra_options} mingw/cygming.opt i386/cygwin.opt"
 	extra_objs="${extra_objs} winnt.o winnt-stubs.o"
 	c_target_objs="${c_target_objs} msformat-c.o"
 	cxx_target_objs="${cxx_target_objs} winnt-cxx.o msformat-c.o"
@@ -2179,9 +2182,9 @@ x86_64-*-cygwin*)
 	need_64bit_isa=yes
 	tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h i386/cygming.h i386/cygwin.h i386/cygwin-w64.h i386/cygwin-stdint.h"
 	xm_file=i386/xm-cygwin.h
-	tmake_file="${tmake_file} i386/t-cygming t-slibgcc"
-	target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc"
-	extra_options="${extra_options} i386/cygming.opt i386/cygwin.opt"
+	tmake_file="${tmake_file} mingw/t-cygming t-slibgcc"
+	target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
+	extra_options="${extra_options} mingw/cygming.opt i386/cygwin.opt"
 	extra_objs="${extra_objs} winnt.o winnt-stubs.o"
 	c_target_objs="${c_target_objs} msformat-c.o"
 	cxx_target_objs="${cxx_target_objs} winnt-cxx.o msformat-c.o"
@@ -2217,7 +2220,7 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
 	if test x$enable_threads = xmcf ; then
 		tm_file="${tm_file} i386/mingw-mcfgthread.h"
 	fi
-	tm_file="${tm_file} i386/mingw32.h"
+	tm_file="${tm_file} mingw/mingw32.h"
 	# This makes the logic if mingw's or the w64 feature set has to be used
 	case ${target} in
 		*-w64-*)
@@ -2246,8 +2249,8 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
 		*)
 			;;
 	esac
-	tm_file="${tm_file} i386/mingw-stdint.h"
-	tmake_file="${tmake_file} t-winnt i386/t-cygming t-slibgcc"
+	tm_file="${tm_file} mingw/mingw-stdint.h"
+	tmake_file="${tmake_file} t-winnt mingw/t-cygming t-slibgcc"
         case ${target} in
                x86_64-w64-*)
                		tmake_file="${tmake_file} i386/t-mingw-w64"
@@ -2257,8 +2260,8 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
 			;;
 	esac
         native_system_header_dir=/mingw/include
-	target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc"
-	extra_options="${extra_options} i386/cygming.opt i386/mingw.opt"
+	target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
+	extra_options="${extra_options} mingw/cygming.opt mingw/mingw.opt"
 	case ${target} in
 		*-w64-*)
 			extra_options="${extra_options} i386/mingw-w64.opt"
diff --git a/gcc/config/i386/cygming.opt b/gcc/config/mingw/cygming.opt
similarity index 100%
rename from gcc/config/i386/cygming.opt
rename to gcc/config/mingw/cygming.opt
diff --git a/gcc/config/i386/cygming.opt.urls b/gcc/config/mingw/cygming.opt.urls
similarity index 100%
rename from gcc/config/i386/cygming.opt.urls
rename to gcc/config/mingw/cygming.opt.urls
diff --git a/gcc/config/i386/cygwin-d.cc b/gcc/config/mingw/cygwin-d.cc
similarity index 100%
rename from gcc/config/i386/cygwin-d.cc
rename to gcc/config/mingw/cygwin-d.cc
diff --git a/gcc/config/i386/mingw-stdint.h b/gcc/config/mingw/mingw-stdint.h
similarity index 100%
rename from gcc/config/i386/mingw-stdint.h
rename to gcc/config/mingw/mingw-stdint.h
diff --git a/gcc/config/i386/mingw.opt b/gcc/config/mingw/mingw.opt
similarity index 100%
rename from gcc/config/i386/mingw.opt
rename to gcc/config/mingw/mingw.opt
diff --git a/gcc/config/i386/mingw.opt.urls b/gcc/config/mingw/mingw.opt.urls
similarity index 100%
rename from gcc/config/i386/mingw.opt.urls
rename to gcc/config/mingw/mingw.opt.urls
diff --git a/gcc/config/i386/mingw32.h b/gcc/config/mingw/mingw32.h
similarity index 100%
rename from gcc/config/i386/mingw32.h
rename to gcc/config/mingw/mingw32.h
diff --git a/gcc/config/i386/msformat-c.cc b/gcc/config/mingw/msformat-c.cc
similarity index 100%
rename from gcc/config/i386/msformat-c.cc
rename to gcc/config/mingw/msformat-c.cc
diff --git a/gcc/config/i386/t-cygming b/gcc/config/mingw/t-cygming
similarity index 73%
rename from gcc/config/i386/t-cygming
rename to gcc/config/mingw/t-cygming
index af01f69acd1..f5de941c8e5 100644
--- a/gcc/config/i386/t-cygming
+++ b/gcc/config/mingw/t-cygming
@@ -20,37 +20,40 @@
 # doing the build, it may not be installed yet.
 LIMITS_H_TEST = true
 
-winnt.o: $(srcdir)/config/i386/winnt.cc $(CONFIG_H) $(SYSTEM_H) coretypes.h \
+winnt.o: $(srcdir)/config/mingw/winnt.cc $(CONFIG_H) $(SYSTEM_H) coretypes.h \
   $(TM_H) $(RTL_H) $(REGS_H) hard-reg-set.h output.h $(TREE_H) flags.h \
   $(TM_P_H) $(HASH_TABLE_H) $(GGC_H) $(LTO_STREAMER_H)
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
-	$(srcdir)/config/i386/winnt.cc
+	$(srcdir)/config/mingw/winnt.cc
 
-winnt-cxx.o: $(srcdir)/config/i386/winnt-cxx.cc $(CONFIG_H) $(SYSTEM_H) coretypes.h \
+winnt-cxx.o: $(srcdir)/config/mingw/winnt-cxx.cc $(CONFIG_H) $(SYSTEM_H) \
+  coretypes.h \
   $(TM_H) $(TREE_H) flags.h \
   $(TM_P_H) $(HASHTAB_H) $(GGC_H)
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
-	$(srcdir)/config/i386/winnt-cxx.cc
+	$(srcdir)/config/mingw/winnt-cxx.cc
 
 
-winnt-stubs.o: $(srcdir)/config/i386/winnt-stubs.cc $(CONFIG_H) $(SYSTEM_H) coretypes.h \
+winnt-stubs.o: $(srcdir)/config/mingw/winnt-stubs.cc $(CONFIG_H) $(SYSTEM_H) \
+  coretypes.h \
   $(TM_H) $(RTL_H) $(REGS_H) hard-reg-set.h output.h $(TREE_H) flags.h \
   $(TM_P_H) $(HASHTAB_H) $(GGC_H)
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
-	$(srcdir)/config/i386/winnt-stubs.cc
+	$(srcdir)/config/mingw/winnt-stubs.cc
 
-cygwin-d.o: $(srcdir)/config/i386/cygwin-d.cc
+cygwin-d.o: $(srcdir)/config/mingw/cygwin-d.cc
 	$(COMPILE) $<
 	$(POSTCOMPILE)
 
-winnt-d.o: $(srcdir)/config/i386/winnt-d.cc
+winnt-d.o: $(srcdir)/config/mingw/winnt-d.cc
 	$(COMPILE) $<
 	$(POSTCOMPILE)
 
-msformat-c.o: $(srcdir)/config/i386/msformat-c.cc $(CONFIG_H) $(SYSTEM_H) coretypes.h \
+msformat-c.o: $(srcdir)/config/mingw/msformat-c.cc $(CONFIG_H) $(SYSTEM_H) \
+  coretypes.h \
   $(TM_H) $(RTL_H) $(REGS_H) hard-reg-set.h output.h $(TREE_H) flags.h \
   $(TM_P_H) $(HASHTAB_H) $(GGC_H)
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
-	$(srcdir)/config/i386/msformat-c.cc
+	$(srcdir)/config/mingw/msformat-c.cc
 
 STMP_FIXINC=stmp-fixinc
diff --git a/gcc/config/i386/winnt-cxx.cc b/gcc/config/mingw/winnt-cxx.cc
similarity index 100%
rename from gcc/config/i386/winnt-cxx.cc
rename to gcc/config/mingw/winnt-cxx.cc
diff --git a/gcc/config/i386/winnt-d.cc b/gcc/config/mingw/winnt-d.cc
similarity index 100%
rename from gcc/config/i386/winnt-d.cc
rename to gcc/config/mingw/winnt-d.cc
diff --git a/gcc/config/i386/winnt-stubs.cc b/gcc/config/mingw/winnt-stubs.cc
similarity index 100%
rename from gcc/config/i386/winnt-stubs.cc
rename to gcc/config/mingw/winnt-stubs.cc
diff --git a/gcc/config/i386/winnt.cc b/gcc/config/mingw/winnt.cc
similarity index 100%
rename from gcc/config/i386/winnt.cc
rename to gcc/config/mingw/winnt.cc
-- 
2.25.1

[PATCH v1 06/13] Rename section and encoding functions from i386 which will be used in aarch64

[Evgeny Karpov]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: v1-0006-Rename-section-and-encoding-functions-from-i386-w.txt --]
[-- Type: text/plain, Size: 10303 bytes --]

From 69561787206b968b5a86c48ca9c9f9073761ed78 Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Tue, 20 Feb 2024 17:22:31 +0100
Subject: [PATCH v1 06/13] Rename section and encoding functions from i386
 which will be used in aarch64

gcc/ChangeLog:

	* config/i386/cygming.h (SUBTARGET_ENCODE_SECTION_INFO):
	Rename functions in mingw folder which will be reused for
	aarch64.
	(TARGET_ASM_UNIQUE_SECTION): Likewise.
	(TARGET_ASM_NAMED_SECTION): Likewise.
	(TARGET_SECTION_TYPE_FLAGS): Likewise.
	(ASM_DECLARE_COLD_FUNCTION_NAME): Likewise.
	(ASM_OUTPUT_EXTERNAL_LIBCALL): Likewise.
	* config/i386/i386-protos.h (i386_pe_unique_section):
	Rename into ...
	(mingw_pe_unique_section): ... this.
	(i386_pe_declare_function_type): Rename into ...
	(mingw_pe_declare_function_type): ... this.
	(i386_pe_encode_section_info): Rename into ...
	(mingw_pe_encode_section_info): ... this.
	(i386_pe_maybe_record_exported_symbol): Rename into ...
	(mingw_pe_maybe_record_exported_symbol): ... this.
	(i386_pe_section_type_flags): Rename into ...
	(mingw_pe_section_type_flags): ... this.
	(i386_pe_asm_named_section): Rename into ...
	(mingw_pe_asm_named_section): ... this.
	* config/mingw/winnt.cc (i386_pe_encode_section_info):
	Rename into ...
	(mingw_pe_encode_section_info): ... this.
	(i386_pe_unique_section): Rename into ...
	(mingw_pe_unique_section): ... this.
	(i386_pe_section_type_flags): Rename into ...
	(mingw_pe_section_type_flags): ... this.
	(i386_pe_asm_named_section): Rename into ...
	(mingw_pe_asm_named_section): ... this.
	(i386_pe_asm_output_aligned_decl_common): Likewise.
	(i386_pe_declare_function_type): Rename into ...
	(mingw_pe_declare_function_type): ... this.
	(i386_pe_maybe_record_exported_symbol): Rename into ...
	(mingw_pe_maybe_record_exported_symbol): ... this.
	(i386_pe_start_function): Likewise.
	* varasm.cc (switch_to_comdat_section): Likewise.
---
 gcc/config/i386/cygming.h     | 18 +++++++++---------
 gcc/config/i386/i386-protos.h | 12 ++++++------
 gcc/config/mingw/winnt.cc     | 22 +++++++++++-----------
 gcc/varasm.cc                 |  2 +-
 4 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index 1af5bc380a5..beedf7c398a 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -219,7 +219,7 @@ do {									\
    section and we need to set DECL_SECTION_NAME so we do that here.
    Note that we can be called twice on the same decl.  */
 
-#define SUBTARGET_ENCODE_SECTION_INFO  i386_pe_encode_section_info
+#define SUBTARGET_ENCODE_SECTION_INFO  mingw_pe_encode_section_info
 
 /* Local and global relocs can be placed always into readonly memory
    for PE-COFF targets.  */
@@ -235,7 +235,7 @@ do {									\
 #undef ASM_DECLARE_OBJECT_NAME
 #define ASM_DECLARE_OBJECT_NAME(STREAM, NAME, DECL)	\
 do {							\
-  i386_pe_maybe_record_exported_symbol (DECL, NAME, 1);	\
+  mingw_pe_maybe_record_exported_symbol (DECL, NAME, 1);	\
   ASM_OUTPUT_LABEL ((STREAM), (NAME));			\
 } while (0)
 
@@ -283,16 +283,16 @@ do {						\
 /* Windows uses explicit import from shared libraries.  */
 #define MULTIPLE_SYMBOL_SPACES 1
 
-#define TARGET_ASM_UNIQUE_SECTION i386_pe_unique_section
+#define TARGET_ASM_UNIQUE_SECTION mingw_pe_unique_section
 #define TARGET_ASM_FUNCTION_RODATA_SECTION default_no_function_rodata_section
 
 #define SUPPORTS_ONE_ONLY 1
 
 /* Switch into a generic section.  */
-#define TARGET_ASM_NAMED_SECTION  i386_pe_asm_named_section
+#define TARGET_ASM_NAMED_SECTION  mingw_pe_asm_named_section
 
 /* Select attributes for named sections.  */
-#define TARGET_SECTION_TYPE_FLAGS  i386_pe_section_type_flags
+#define TARGET_SECTION_TYPE_FLAGS  mingw_pe_section_type_flags
 
 /* Write the extra assembler code needed to declare a function
    properly.  */
@@ -307,7 +307,7 @@ do {						\
 #define ASM_DECLARE_COLD_FUNCTION_NAME(FILE, NAME, DECL)	\
   do								\
     {								\
-      i386_pe_declare_function_type (FILE, NAME, 0);		\
+      mingw_pe_declare_function_type (FILE, NAME, 0);		\
       i386_pe_seh_cold_init (FILE, NAME);			\
       ASM_OUTPUT_LABEL (FILE, NAME);				\
     }								\
@@ -333,7 +333,7 @@ do {						\
 
 /* Declare the type properly for any external libcall.  */
 #define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN) \
-  i386_pe_declare_function_type (FILE, XSTR (FUN, 0), 1)
+  mingw_pe_declare_function_type (FILE, XSTR (FUN, 0), 1)
 
 /* This says out to put a global symbol in the BSS section.  */
 #undef ASM_OUTPUT_ALIGNED_BSS
@@ -416,9 +416,9 @@ do {						\
     {									\
       const char *alias							\
 	= IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (DECL));		\
-      i386_pe_maybe_record_exported_symbol (DECL, alias, 0);		\
+      mingw_pe_maybe_record_exported_symbol (DECL, alias, 0);		\
       if (TREE_CODE (DECL) == FUNCTION_DECL)				\
-	i386_pe_declare_function_type (STREAM, alias,			\
+	mingw_pe_declare_function_type (STREAM, alias,			\
 				       TREE_PUBLIC (DECL));		\
       ASM_OUTPUT_DEF (STREAM, alias, IDENTIFIER_POINTER (TARGET));	\
     } while (0)
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index 46214a63974..dbc861fb1ea 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -295,16 +295,16 @@ extern void ix86_target_macros (void);
 extern void ix86_register_pragmas (void);
 
 /* In winnt.cc  */
-extern void i386_pe_unique_section (tree, int);
-extern void i386_pe_declare_function_type (FILE *, const char *, int);
+extern void mingw_pe_unique_section (tree, int);
+extern void mingw_pe_declare_function_type (FILE *, const char *, int);
 extern void i386_pe_record_external_function (tree, const char *);
-extern void i386_pe_maybe_record_exported_symbol (tree, const char *, int);
-extern void i386_pe_encode_section_info (tree, rtx, int);
+extern void mingw_pe_maybe_record_exported_symbol (tree, const char *, int);
+extern void mingw_pe_encode_section_info (tree, rtx, int);
 extern bool i386_pe_binds_local_p (const_tree);
 extern const char *i386_pe_strip_name_encoding_full (const char *);
 extern bool i386_pe_valid_dllimport_attribute_p (const_tree);
-extern unsigned int i386_pe_section_type_flags (tree, const char *, int);
-extern void i386_pe_asm_named_section (const char *, unsigned int, tree);
+extern unsigned int mingw_pe_section_type_flags (tree, const char *, int);
+extern void mingw_pe_asm_named_section (const char *, unsigned int, tree);
 extern void i386_pe_asm_output_aligned_decl_common (FILE *, tree,
 						    const char *,
 						    HOST_WIDE_INT,
diff --git a/gcc/config/mingw/winnt.cc b/gcc/config/mingw/winnt.cc
index 9b315898fca..1ed383155d0 100644
--- a/gcc/config/mingw/winnt.cc
+++ b/gcc/config/mingw/winnt.cc
@@ -293,7 +293,7 @@ i386_pe_mangle_assembler_name (const char *name)
 }
 
 void
-i386_pe_encode_section_info (tree decl, rtx rtl, int first)
+mingw_pe_encode_section_info (tree decl, rtx rtl, int first)
 {
   rtx symbol;
   int flags;
@@ -384,7 +384,7 @@ i386_pe_strip_name_encoding_full (const char *str)
 }
 
 void
-i386_pe_unique_section (tree decl, int reloc)
+mingw_pe_unique_section (tree decl, int reloc)
 {
   int len;
   const char *name, *prefix;
@@ -442,7 +442,7 @@ i386_pe_reloc_rw_mask (void)
 #define SECTION_PE_SHARED	SECTION_MACH_DEP
 
 unsigned int
-i386_pe_section_type_flags (tree decl, const char *, int reloc)
+mingw_pe_section_type_flags (tree decl, const char *, int reloc)
 {
   unsigned int flags;
 
@@ -471,7 +471,7 @@ i386_pe_section_type_flags (tree decl, const char *, int reloc)
 }
 
 void
-i386_pe_asm_named_section (const char *name, unsigned int flags, 
+mingw_pe_asm_named_section (const char *name, unsigned int flags,
 			   tree decl)
 {
   char flagchars[8], *f = flagchars;
@@ -548,7 +548,7 @@ i386_pe_asm_output_aligned_decl_common (FILE *stream, tree decl,
   rounded = (rounded / (BIGGEST_ALIGNMENT / BITS_PER_UNIT)
 	     * (BIGGEST_ALIGNMENT / BITS_PER_UNIT));
   
-  i386_pe_maybe_record_exported_symbol (decl, name, 1);
+  mingw_pe_maybe_record_exported_symbol (decl, name, 1);
 
   fprintf (stream, "\t.comm\t");
   assemble_name (stream, name);
@@ -574,7 +574,7 @@ i386_pe_asm_output_aligned_decl_common (FILE *stream, tree decl,
    visible.  */
 
 void
-i386_pe_declare_function_type (FILE *file, const char *name, int pub)
+mingw_pe_declare_function_type (FILE *file, const char *name, int pub)
 {
   fprintf (file, "\t.def\t");
   assemble_name (file, name);
@@ -641,7 +641,7 @@ static GTY(()) struct stub_list *stub_head;
    the LTO marker.  */
 
 void
-i386_pe_maybe_record_exported_symbol (tree decl, const char *name, int is_data)
+mingw_pe_maybe_record_exported_symbol (tree decl, const char *name, int is_data)
 {
   rtx symbol;
   struct export_list *p;
@@ -761,11 +761,11 @@ i386_pe_file_end (void)
 	     the real function so that an (unused) import is created.  */
 	  const char *realsym = i386_find_on_wrapper_list (p->name);
 	  if (realsym)
-	    i386_pe_declare_function_type (asm_out_file,
+	    mingw_pe_declare_function_type (asm_out_file,
 		concat ("__real_", realsym, NULL), TREE_PUBLIC (decl));
 #endif /* CXX_WRAP_SPEC_LIST */
 	  TREE_ASM_WRITTEN (decl) = 1;
-	  i386_pe_declare_function_type (asm_out_file, p->name,
+	  mingw_pe_declare_function_type (asm_out_file, p->name,
 					 TREE_PUBLIC (decl));
 	}
     }
@@ -1354,8 +1354,8 @@ i386_pe_seh_init_sections (void)
 void
 i386_pe_start_function (FILE *f, const char *name, tree decl)
 {
-  i386_pe_maybe_record_exported_symbol (decl, name, 0);
-  i386_pe_declare_function_type (f, name, TREE_PUBLIC (decl));
+  mingw_pe_maybe_record_exported_symbol (decl, name, 0);
+  mingw_pe_declare_function_type (f, name, TREE_PUBLIC (decl));
   /* In case section was altered by debugging output.  */
   if (decl != NULL_TREE)
     switch_to_section (function_section (decl));
diff --git a/gcc/varasm.cc b/gcc/varasm.cc
index 008d9b13303..b011ea033c9 100644
--- a/gcc/varasm.cc
+++ b/gcc/varasm.cc
@@ -8626,7 +8626,7 @@ switch_to_comdat_section (section *sect, tree decl)
      everything in .vtable_map_vars at the end.
 
      A fix could be made in
-     gcc/config/i386/winnt.cc: i386_pe_unique_section.  */
+     gcc/config/i386/winnt.cc: mingw_pe_unique_section.  */
   if (TARGET_PECOFF)
     {
       char *name;
-- 
2.25.1

[PATCH v1 07/13] Exclude i386 functionality from aarch64 build

[Evgeny Karpov]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: v1-0007-Exclude-i386-functionality-from-aarch64-build.txt --]
[-- Type: text/plain, Size: 2007 bytes --]

From 1b7451707709d6745efb52b54b17e798d7375aac Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Tue, 20 Feb 2024 17:31:58 +0100
Subject: [PATCH v1 07/13] Exclude i386 functionality from aarch64 build

ix86_get_callcvt is used for i386 build and needs to be excluded to
reuse winnt.cc in aarch64.

gcc/ChangeLog:

	* config/mingw/winnt.cc (defined): Use TARGET_ARM64_MS_ABI to
	exclude ix86_get_callcvt.
	(i386_pe_maybe_mangle_decl_assembler_name): Likewise.
	(i386_pe_mangle_decl_assembler_name): Likewise.
---
 gcc/config/mingw/winnt.cc | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/gcc/config/mingw/winnt.cc b/gcc/config/mingw/winnt.cc
index 1ed383155d0..bd86cfb1156 100644
--- a/gcc/config/mingw/winnt.cc
+++ b/gcc/config/mingw/winnt.cc
@@ -224,6 +224,8 @@ gen_stdcall_or_fastcall_suffix (tree decl, tree id, bool fastcall)
   return get_identifier (new_str);
 }
 
+#if !defined (TARGET_ARM64_MS_ABI)
+
 /* Maybe decorate and get a new identifier for the DECL of a stdcall or
    fastcall function. The original identifier is supplied in ID. */
 
@@ -250,6 +252,8 @@ i386_pe_maybe_mangle_decl_assembler_name (tree decl, tree id)
   return new_id;
 }
 
+#endif
+
 /* Emit an assembler directive to set symbol for DECL visibility to
    the visibility type VIS, which must not be VISIBILITY_DEFAULT.
    As for PE there is no hidden support in gas, we just warn for
@@ -266,6 +270,8 @@ i386_pe_assemble_visibility (tree decl, int)
 			      "in this configuration; ignored");
 }
 
+#if !defined (TARGET_ARM64_MS_ABI)
+
 /* This is used as a target hook to modify the DECL_ASSEMBLER_NAME
    in the language-independent default hook
    langhooks,c:lhd_set_decl_assembler_name ()
@@ -278,6 +284,8 @@ i386_pe_mangle_decl_assembler_name (tree decl, tree id)
   return (new_id ? new_id : id);
 }
 
+#endif
+
 /* This hook behaves the same as varasm.cc/assemble_name(), but
    generates the name into memory rather than outputting it to
    a file stream.  */
-- 
2.25.1

[PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[Evgeny Karpov]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: v1-0008-aarch64-Add-Cygwin-and-MinGW-environments-for-AAr.txt --]
[-- Type: text/plain, Size: 7561 bytes --]

From 1ea6efa6f88d131884ecef21c4b5d2ecbab14ea7 Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Tue, 20 Feb 2024 18:06:36 +0100
Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for
 AArch64

Define Cygwin and MinGW environment such as types, SEH definitions,
shared libraries, etc.

gcc/ChangeLog:

	* config.gcc: Add Cygwin and MinGW difinitions.
	* config/aarch64/aarch64-protos.h
	(mingw_pe_maybe_record_exported_symbol): Declare functions
	which are used in Cygwin and MinGW environment.
	(mingw_pe_section_type_flags): Likewise.
	(mingw_pe_unique_section): Likewise.
	(mingw_pe_encode_section_info): Likewise.
	* config/aarch64/cygming.h: New file.
---
 gcc/config.gcc                      |   1 +
 gcc/config/aarch64/aarch64-protos.h |   5 +
 gcc/config/aarch64/cygming.h        | 178 ++++++++++++++++++++++++++++
 3 files changed, 184 insertions(+)
 create mode 100644 gcc/config/aarch64/cygming.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 498ee702607..96e3508eb30 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1265,6 +1265,7 @@ aarch64*-*-linux*)
 	;;
 aarch64*-*-mingw*)
 	tm_file="${tm_file} aarch64/aarch64-coff.h"
+	tm_file="${tm_file} aarch64/cygming.h"
 	tm_file="${tm_file} mingw/mingw32.h"
 	tm_file="${tm_file} mingw/mingw-stdint.h"
 	tmake_file="${tmake_file} aarch64/t-aarch64"
diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index a0b142e0b94..6d85452b0f6 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -1109,6 +1109,11 @@ extern void aarch64_output_patchable_area (unsigned int, bool);
 
 extern void aarch64_adjust_reg_alloc_order ();
 
+extern void mingw_pe_maybe_record_exported_symbol (tree, const char *, int);
+extern unsigned int mingw_pe_section_type_flags (tree, const char *, int);
+extern void mingw_pe_unique_section (tree, int);
+extern void mingw_pe_encode_section_info (tree, rtx, int);
+
 bool aarch64_optimize_mode_switching (aarch64_mode_entity);
 void aarch64_restore_za (rtx);
 
diff --git a/gcc/config/aarch64/cygming.h b/gcc/config/aarch64/cygming.h
new file mode 100644
index 00000000000..cf47184eb66
--- /dev/null
+++ b/gcc/config/aarch64/cygming.h
@@ -0,0 +1,178 @@
+/* Operating system specific defines to be used when targeting GCC for
+   hosting on Windows32, using a Unix style C library and tools.
+   Copyright (C) 1995-2024 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+<http://www.gnu.org/licenses/>.  */
+
+#ifndef GCC_AARCH64_CYGMING_H
+#define GCC_AARCH64_CYGMING_H
+
+#undef PREFERRED_DEBUGGING_TYPE
+#define PREFERRED_DEBUGGING_TYPE DINFO_TYPE_NONE
+
+#define FASTCALL_PREFIX '@'
+
+#define print_reg(rtx, code, file)
+
+#define SYMBOL_FLAG_DLLIMPORT 0
+#define SYMBOL_FLAG_DLLEXPORT 0
+
+#define SYMBOL_REF_DLLEXPORT_P(X) \
+	((SYMBOL_REF_FLAGS (X) & SYMBOL_FLAG_DLLEXPORT) != 0)
+
+#undef TARGET_SEH
+#define TARGET_SEH 0
+
+#define SSE_REGNO_P(N) 0
+#define GENERAL_REGNO_P(N) 0
+#define SEH_MAX_FRAME_SIZE 0
+
+#undef DEFAULT_ABI
+#define DEFAULT_ABI MS_ABI
+
+#undef TARGET_PECOFF
+#define TARGET_PECOFF 1
+
+#include <stdbool.h>
+#ifdef __MINGW32__
+#include <stdio.h>
+#endif
+
+extern void mingw_pe_asm_named_section (const char *, unsigned int, tree);
+extern void mingw_pe_declare_function_type (FILE *file, const char *name,
+	int pub);
+
+#define TARGET_ASM_NAMED_SECTION  mingw_pe_asm_named_section
+
+/* Select attributes for named sections.  */
+#define TARGET_SECTION_TYPE_FLAGS  mingw_pe_section_type_flags
+
+#define TARGET_ASM_UNIQUE_SECTION mingw_pe_unique_section
+#define TARGET_ENCODE_SECTION_INFO  mingw_pe_encode_section_info
+
+/* Declare the type properly for any external libcall.  */
+#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN) \
+  mingw_pe_declare_function_type (FILE, XSTR (FUN, 0), 1)
+
+#define TARGET_OS_CPP_BUILTINS()					\
+  do									\
+    {									\
+      builtin_define ("__MSVCRT__");					\
+      builtin_define ("__MINGW32__");					\
+      builtin_define ("_WIN32");					\
+      builtin_define_std ("WIN32");					\
+      builtin_define_std ("WINNT");					\
+      builtin_define_with_int_value ("_INTEGRAL_MAX_BITS",		\
+				TYPE_PRECISION (intmax_type_node));	\
+      builtin_define ("__MINGW64__");					\
+      builtin_define_std ("WIN64");					\
+      builtin_define ("_WIN64");					\
+      builtin_define ("__stdcall=__attribute__((__stdcall__))");	\
+      builtin_define ("__fastcall=__attribute__((__fastcall__))");	\
+      builtin_define ("__thiscall=__attribute__((__thiscall__))");	\
+      builtin_define ("__cdecl=__attribute__((__cdecl__))");		\
+    }									\
+  while (0)
+
+/* Windows64 continues to use a 32-bit long type.  */
+#undef LONG_TYPE_SIZE
+#define LONG_TYPE_SIZE 32
+
+#undef DEFAULT_SIGNED_CHAR
+#define DEFAULT_SIGNED_CHAR 1
+
+#undef SIZE_TYPE
+#undef PTRDIFF_TYPE
+#define SIZE_TYPE "long long unsigned int"
+#define PTRDIFF_TYPE "long long int"
+
+#undef WCHAR_TYPE_SIZE
+#undef WCHAR_TYPE
+#define WCHAR_TYPE_SIZE 16
+#define WCHAR_TYPE "short unsigned int"
+
+#define drectve_section() \
+  (fprintf (asm_out_file, "\t.section\t.drectve\n"), \
+   in_section = NULL)
+
+
+/* Enable alias attribute support.  */
+#ifndef SET_ASM_OP
+#define SET_ASM_OP "\t.set\t"
+#endif
+
+/* GNU as supports weak symbols on PECOFF.  */
+#ifdef HAVE_GAS_WEAK
+#define ASM_WEAKEN_LABEL(FILE, NAME)	\
+  do					\
+    {					\
+      fputs ("\t.weak\t", (FILE));	\
+      assemble_name ((FILE), (NAME));	\
+      fputc ('\n', (FILE));		\
+    }					\
+  while (0)
+
+#endif /* HAVE_GAS_WEAK.  */
+
+/* Get tree.cc to declare a target-specific specialization of
+   merge_decl_attributes.  */
+#define TARGET_DLLIMPORT_DECL_ATTRIBUTES 1
+
+#define ASM_OUTPUT_ADDR_DIFF_ELT(STREAM, BODY, VALUE, REL)		\
+  do {									\
+    switch (GET_MODE (BODY))						\
+      {									\
+      case E_QImode:							\
+	asm_fprintf (STREAM, "\t.byte\t(%LL%d - %LLrtx%d) / 4\n",	\
+		     VALUE, REL);					\
+	break;								\
+      case E_HImode:							\
+	asm_fprintf (STREAM, "\t.2byte\t(%LL%d - %LLrtx%d) / 4\n",	\
+		     VALUE, REL);					\
+	break;								\
+      case E_SImode:							\
+      case E_DImode: /* See comment in aarch64_output_casesi.  */	\
+	asm_fprintf (STREAM, "\t.word\t(%LL%d - %LLrtx%d) / 4\n",	\
+		     VALUE, REL);					\
+	break;								\
+      default:								\
+	gcc_unreachable ();						\
+      }									\
+  } while (0)
+
+#define READONLY_DATA_SECTION_ASM_OP "\t.section\t.rdata,\"dr\""
+
+#undef  SUBTARGET_OVERRIDE_OPTIONS
+#define SUBTARGET_OVERRIDE_OPTIONS			\
+  do {							\
+    flag_stack_check = STATIC_BUILTIN_STACK_CHECK;	\
+  } while (0)
+
+
+#define SUPPORTS_ONE_ONLY 1
+
+/* Define this to be nonzero if static stack checking is supported.  */
+#define STACK_CHECK_STATIC_BUILTIN 1
+
+#ifndef HAVE_GAS_ALIGNED_COMM
+# define HAVE_GAS_ALIGNED_COMM 0
+#endif
+
+#undef MAX_OFILE_ALIGNMENT
+#define MAX_OFILE_ALIGNMENT (8192 * 8)
+
+#endif
-- 
2.25.1

[PATCH v1 09/13] aarch64: Add SEH to machine_function

[Evgeny Karpov]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: v1-0009-aarch64-Add-SEH-to-machine_function.txt --]
[-- Type: text/plain, Size: 1309 bytes --]

From e82f58dc1ef9405a86f6e77c29fe2359128a22aa Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Tue, 20 Feb 2024 18:10:08 +0100
Subject: [PATCH v1 09/13] aarch64: Add SEH to machine_function

SEH is not enabled in aarch64-w64-mingw32 target yet. However, it is
needed to be declared in machine_function for reusing winnt.cc.

gcc/ChangeLog:

	* config/aarch64/aarch64.h (struct seh_frame_state): Declare SEH
	structure in machine_function.
	(GTY): Add SEH field.
---
 gcc/config/aarch64/aarch64.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 36916e7a97d..7f025e74a66 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -1055,6 +1055,9 @@ struct GTY (()) aarch64_frame
   bool is_scs_enabled;
 };
 
+/* Private to winnt.cc.  */
+struct seh_frame_state;
+
 #ifdef hash_set_h
 typedef struct GTY (()) machine_function
 {
@@ -1095,6 +1098,9 @@ typedef struct GTY (()) machine_function
      still exists and still fulfils its original purpose. the same register
      can be reused by other code.  */
   rtx_insn *advsimd_zero_insn;
+
+  /* During SEH output, this is non-null.  */
+  struct seh_frame_state * GTY ((skip (""))) seh;
 } machine_function;
 #endif
 #endif
-- 
2.25.1

[PATCH v1 10/13] Rename "x86 Windows Options" to "Cygwin and MinGW Options"

[Evgeny Karpov]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: v1-0010-Rename-x86-Windows-Options-to-Cygwin-and-MinGW-Op.txt --]
[-- Type: text/plain, Size: 5413 bytes --]

From 7d27cda54a56e93ba63c5cf4d47e5c865bdae525 Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Tue, 20 Feb 2024 15:45:53 +0100
Subject: [PATCH v1 10/13] Rename "x86 Windows Options" to "Cygwin and MinGW
 Options"

Rename "x86 Windows Options" to "Cygwin and MinGW Options".
It will be used also for AArch64.

gcc/ChangeLog:

	* config/i386/mingw-w64.opt.urls: Rename options' name and
	regenerate option URLs.
	* config/lynx.opt.urls: Likewise.
	* config/mingw/cygming.opt.urls: Likewise.
	* config/mingw/mingw.opt.urls: Likewise.
	* doc/invoke.texi: Likewise.
---
 gcc/config/i386/mingw-w64.opt.urls |  2 +-
 gcc/config/lynx.opt.urls           |  2 +-
 gcc/config/mingw/cygming.opt.urls  | 18 +++++++++---------
 gcc/config/mingw/mingw.opt.urls    |  2 +-
 gcc/doc/invoke.texi                | 12 ++++++------
 5 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/gcc/config/i386/mingw-w64.opt.urls b/gcc/config/i386/mingw-w64.opt.urls
index 6bb53ef29b2..5cceba1d1a1 100644
--- a/gcc/config/i386/mingw-w64.opt.urls
+++ b/gcc/config/i386/mingw-w64.opt.urls
@@ -1,5 +1,5 @@
 ; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/mingw-w64.opt and generated HTML
 
 municode
-UrlSuffix(gcc/x86-Windows-Options.html#index-municode)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-municode)
 
diff --git a/gcc/config/lynx.opt.urls b/gcc/config/lynx.opt.urls
index 63e7b9c4b33..b547138f7ff 100644
--- a/gcc/config/lynx.opt.urls
+++ b/gcc/config/lynx.opt.urls
@@ -1,5 +1,5 @@
 ; Autogenerated by regenerate-opt-urls.py from gcc/config/lynx.opt and generated HTML
 
 mthreads
-UrlSuffix(gcc/x86-Windows-Options.html#index-mthreads-1)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1)
 
diff --git a/gcc/config/mingw/cygming.opt.urls b/gcc/config/mingw/cygming.opt.urls
index 87799befe3c..c624e22e442 100644
--- a/gcc/config/mingw/cygming.opt.urls
+++ b/gcc/config/mingw/cygming.opt.urls
@@ -1,30 +1,30 @@
 ; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/cygming.opt and generated HTML
 
 mconsole
-UrlSuffix(gcc/x86-Windows-Options.html#index-mconsole)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mconsole)
 
 mdll
-UrlSuffix(gcc/x86-Windows-Options.html#index-mdll)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mdll)
 
 mnop-fun-dllimport
-UrlSuffix(gcc/x86-Windows-Options.html#index-mnop-fun-dllimport)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mnop-fun-dllimport)
 
 ; skipping UrlSuffix for 'mthreads' due to multiple URLs:
+;   duplicate: 'gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1'
 ;   duplicate: 'gcc/x86-Options.html#index-mthreads'
-;   duplicate: 'gcc/x86-Windows-Options.html#index-mthreads-1'
 
 mwin32
-UrlSuffix(gcc/x86-Windows-Options.html#index-mwin32)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mwin32)
 
 mwindows
-UrlSuffix(gcc/x86-Windows-Options.html#index-mwindows)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mwindows)
 
 mpe-aligned-commons
-UrlSuffix(gcc/x86-Windows-Options.html#index-mpe-aligned-commons)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mpe-aligned-commons)
 
 fset-stack-executable
-UrlSuffix(gcc/x86-Windows-Options.html#index-fno-set-stack-executable)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-fno-set-stack-executable)
 
 fwritable-relocated-rdata
-UrlSuffix(gcc/x86-Windows-Options.html#index-fno-writable-relocated-rdata)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-fno-writable-relocated-rdata)
 
diff --git a/gcc/config/mingw/mingw.opt.urls b/gcc/config/mingw/mingw.opt.urls
index 2cbbaadf310..f8ee5be6a53 100644
--- a/gcc/config/mingw/mingw.opt.urls
+++ b/gcc/config/mingw/mingw.opt.urls
@@ -1,7 +1,7 @@
 ; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/mingw.opt and generated HTML
 
 mcrtdll=
-UrlSuffix(gcc/x86-Windows-Options.html#index-mcrtdll)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mcrtdll)
 
 ; skipping UrlSuffix for 'pthread' due to multiple URLs:
 ;   duplicate: 'gcc/Link-Options.html#index-pthread-1'
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e18886e0ac7..eaa1e3dc6d2 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1492,7 +1492,7 @@ See RS/6000 and PowerPC Options.
 -mindirect-branch-cs-prefix -mneeded -mno-direct-extern-access
 -munroll-only-small-loops -mlam=@var{choice}}
 
-@emph{x86 Windows Options}
+@emph{Cygwin and MinGW Options}
 @gccoptlist{-mconsole  -mcrtdll=@var{library}  -mdll
 -mnop-fun-dllimport  -mthread
 -municode  -mwin32  -mwindows  -fno-set-stack-executable}
@@ -20970,6 +20970,7 @@ platform.
 * C6X Options::
 * CRIS Options::
 * C-SKY Options::
+* Cygwin and MinGW Options::
 * Darwin Options::
 * DEC Alpha Options::
 * eBPF Options::
@@ -21014,7 +21015,6 @@ platform.
 * VMS Options::
 * VxWorks Options::
 * x86 Options::
-* x86 Windows Options::
 * Xstormy16 Options::
 * Xtensa Options::
 * zSeries Options::
@@ -36094,10 +36094,10 @@ positions 62:48 can be used for metadata; With @samp{u57}, pointer bits in
 positions 62:57 can be used for metadata.
 @end table
 
-@node x86 Windows Options
-@subsection x86 Windows Options
-@cindex x86 Windows Options
-@cindex Windows Options for x86
+@node Cygwin and MinGW Options
+@subsection Cygwin and MinGW Options
+@cindex Cygwin and MinGW Options
+@cindex Options for Cygwin and MinGW
 
 These additional options are available for Microsoft Windows targets:
 
-- 
2.25.1

[PATCH v1 11/13] aarch64: Build and add objects for Cygwin and MinGW for AArch64

[Evgeny Karpov]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: v1-0011-aarch64-Build-and-add-objects-for-Cygwin-and-MinG.txt --]
[-- Type: text/plain, Size: 1086 bytes --]

From c00d64291446f722dd2268aaca6ca156e9888fe7 Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Tue, 20 Feb 2024 13:55:51 +0100
Subject: [PATCH v1 11/13] aarch64: Build and add objects for Cygwin and MinGW
 for AArch64

gcc/ChangeLog:

	* config.gcc: Build and add objects for Cygwin and MinGW. Add Cygwin
	and MinGW options to the target.
---
 gcc/config.gcc | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 96e3508eb30..3e839eee369 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1270,6 +1270,11 @@ aarch64*-*-mingw*)
 	tm_file="${tm_file} mingw/mingw-stdint.h"
 	tmake_file="${tmake_file} aarch64/t-aarch64"
 	target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
+	extra_options="${extra_options} mingw/cygming.opt mingw/mingw.opt"
+	extra_objs="${extra_objs} winnt.o"
+	c_target_objs="${c_target_objs} msformat-c.o"
+	d_target_objs="${d_target_objs} winnt-d.o"
+	tmake_file="${tmake_file} mingw/t-cygming"
 	case ${enable_threads} in
 	  "" | yes | win32)
 	    thread_file='win32'
-- 
2.25.1

[PATCH v1 12/13] aarch64: Add aarch64-w64-mingw32 target to libatomic

[Evgeny Karpov]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: v1-0012-aarch64-Add-aarch64-w64-mingw32-target-to-libatom.txt --]
[-- Type: text/plain, Size: 791 bytes --]

From d6de6d367f109e5e0b3b0a228e4f3411b53d8e7f Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Mon, 8 Jan 2024 22:19:45 +0100
Subject: [PATCH v1 12/13] aarch64: Add aarch64-w64-mingw32 target to libatomic

libatomic/ChangeLog:

	* configure.tgt: Add aarch64-w64-mingw32 target.
---
 libatomic/configure.tgt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
index 4237f283fe4..eea4c25e061 100644
--- a/libatomic/configure.tgt
+++ b/libatomic/configure.tgt
@@ -44,7 +44,7 @@ case "${target_cpu}" in
   aarch64*)
 	ARCH=aarch64
 	case "${target}" in
-	    aarch64*-*-linux*)
+	    aarch64*-*-linux* | aarch64*-*-mingw*)
 		if test -n "$enable_aarch64_lse"; then
 		    try_ifunc=yes
 		fi
-- 
2.25.1

[PATCH v1 13/13] Add aarch64-w64-mingw32 target to libgcc

[Evgeny Karpov]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: v1-0013-Add-aarch64-w64-mingw32-target-to-libgcc.txt --]
[-- Type: text/plain, Size: 3404 bytes --]

From fa02812c6fb39fd409a27cd09664530f2fabd9e3 Mon Sep 17 00:00:00 2001
From: Zac Walker <zacwalker@microsoft.com>
Date: Mon, 12 Feb 2024 15:22:47 +0100
Subject: [PATCH v1 13/13] Add aarch64-w64-mingw32 target to libgcc

Reuse MinGW definitions from i386 for libgcc. Move reused files to
libgcc/config/mingw folder.

libgcc/ChangeLog:

	* config.host: Add aarch64-w64-mingw32 target. Adjust targets
	after moving MinGW files.
	* config/i386/t-gthr-win32: Moved to...
	* config/mingw/t-gthr-win32: ...here.
	* config/i386/t-mingw-pthread: Moved to...
	* config/mingw/t-mingw-pthread: ...here.
	* config/aarch64/t-no-eh: New file. EH is not yet implemented for
	the target, and the default definition should be disabled.
---
 libgcc/config.host                            | 23 +++++++++++++++----
 libgcc/config/aarch64/t-no-eh                 |  2 ++
 libgcc/config/{i386 => mingw}/t-gthr-win32    |  0
 libgcc/config/{i386 => mingw}/t-mingw-pthread |  0
 4 files changed, 21 insertions(+), 4 deletions(-)
 create mode 100644 libgcc/config/aarch64/t-no-eh
 rename libgcc/config/{i386 => mingw}/t-gthr-win32 (100%)
 rename libgcc/config/{i386 => mingw}/t-mingw-pthread (100%)

diff --git a/libgcc/config.host b/libgcc/config.host
index 59a42d3a01f..3396a84893f 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -456,6 +456,21 @@ aarch64*-*-vxworks7*)
 	tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp t-crtfm"
 	tmake_file="${tmake_file} t-dfprules"
 	;;
+aarch64-*-mingw*)
+	case ${target_thread_file} in
+	  win32)
+	    tmake_thr_file="mingw/t-gthr-win32"
+	    ;;
+	  posix)
+	    tmake_thr_file="mingw/t-mingw-pthread"
+	    ;;
+	esac
+	tmake_file="${tmake_file} ${cpu_type}/t-no-eh ${tmake_thr_file}"
+	tmake_file="${tmake_file} t-dfprules"
+	tmake_file="${tmake_file} ${cpu_type}/t-aarch64"
+	tmake_file="${tmake_file} ${cpu_type}/t-lse"
+	tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp t-crtfm"
+	;;
 alpha*-*-linux*)
 	tmake_file="${tmake_file} alpha/t-alpha alpha/t-ieee t-crtfm alpha/t-linux"
 	extra_parts="$extra_parts crtfastmath.o"
@@ -874,10 +889,10 @@ i[34567]86-*-mingw*)
 	fi
 	case ${target_thread_file} in
 	  win32)
-	    tmake_thr_file="i386/t-gthr-win32"
+	    tmake_thr_file="mingw/t-gthr-win32"
 	    ;;
 	  posix)
-	    tmake_thr_file="i386/t-mingw-pthread"
+	    tmake_thr_file="mingw/t-mingw-pthread"
 	    ;;
 	  mcf)
 	    tmake_thr_file="i386/t-mingw-mcfgthread"
@@ -901,10 +916,10 @@ i[34567]86-*-mingw*)
 x86_64-*-mingw*)
 	case ${target_thread_file} in
 	  win32)
-	    tmake_thr_file="i386/t-gthr-win32"
+	    tmake_thr_file="mingw/t-gthr-win32"
 	    ;;
 	  posix)
-	    tmake_thr_file="i386/t-mingw-pthread"
+	    tmake_thr_file="mingw/t-mingw-pthread"
 	    ;;
 	  mcf)
 	    tmake_thr_file="i386/t-mingw-mcfgthread"
diff --git a/libgcc/config/aarch64/t-no-eh b/libgcc/config/aarch64/t-no-eh
new file mode 100644
index 00000000000..1802339a583
--- /dev/null
+++ b/libgcc/config/aarch64/t-no-eh
@@ -0,0 +1,2 @@
+# Not using EH
+LIB2ADDEH =
diff --git a/libgcc/config/i386/t-gthr-win32 b/libgcc/config/mingw/t-gthr-win32
similarity index 100%
rename from libgcc/config/i386/t-gthr-win32
rename to libgcc/config/mingw/t-gthr-win32
diff --git a/libgcc/config/i386/t-mingw-pthread b/libgcc/config/mingw/t-mingw-pthread
similarity index 100%
rename from libgcc/config/i386/t-mingw-pthread
rename to libgcc/config/mingw/t-mingw-pthread
-- 
2.25.1

Re: [PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[Andrew Pinski]

On Wed, Feb 21, 2024 at 10:38 AM Evgeny Karpov
<Evgeny.Karpov@microsoft.com> wrote:
>
>

In config/i386/winnt.cc there are many x86_64 comments and many
function names that use i386 in them? When moving it seems like better
to rename them and remove references to 86.
I don't see any changes that rename the functions or comments there.

Thanks,
Andrew

Re: [PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[rep.dot.nop]

On 21 February 2024 19:34:43 CET, Evgeny Karpov <Evgeny.Karpov@microsoft.com> wrote:
>

Please use git send-email. Your mail ends up as empty as here, otherwise.

The ChangeLog has to be expressed in present tense, as mandated by the standard; s/Moved/Move/g etc.

In any sane world ( and in gcc ) to fold, respectively a folder, is something else compared to a directory ( which you probably mean when moving a file from one directory to another directory as you seem to do ).

Most of the free world has left COFF behind since several decades, so I won't comment on that. YMMV.

HTH

Re: [PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[Richard Earnshaw (lists)]

On 21/02/2024 21:34, rep.dot.nop@gmail.com wrote:
> On 21 February 2024 19:34:43 CET, Evgeny Karpov <Evgeny.Karpov@microsoft.com> wrote:
>>
> 
> Please use git send-email. Your mail ends up as empty as here, otherwise.

I don't see anything wrong with it; niether does patchwork (https://patchwork.sourceware.org/project/gcc/list/?series=31191) nor does the Linaro CI bot.  So perhaps it's your mailer that's misconfigured.

> 
> The ChangeLog has to be expressed in present tense, as mandated by the standard; s/Moved/Move/g etc.

Agreed, but that's a detail that we can get to once the patch has been properly reviewed.

> 
> In any sane world ( and in gcc ) to fold, respectively a folder, is something else compared to a directory ( which you probably mean when moving a file from one directory to another directory as you seem to do ).
> 
> Most of the free world has left COFF behind since several decades, so I won't comment on that. YMMV.

This isn't helpful.  Windows platforms use (a derivative of) COFF, so that's what the tools need to use when targetting that platform.

R.

Re: [PATCH v1 01/13] Introduce aarch64-w64-mingw32 target

[Richard Earnshaw (lists)]

On 21/02/2024 18:16, Evgeny Karpov wrote:
> 
+aarch64*-*-mingw*)

Other targets are a bit inconsistent here as well, but, as Andrew mentioned, if you don't want to handle big-endian, it might be better to match aarch64-*-mingw* here.

R.

Re: [PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements

[Richard Earnshaw (lists)]

On 21/02/2024 18:26, Evgeny Karpov wrote:
> 
+/* Available call ABIs.  */
+enum calling_abi
+{
+  AARCH64_EABI = 0,
+  MS_ABI = 1
+};
+

The convention in this file seems to be that all enum types to start with aarch64.  Also, the enumeration values should start with the name of the enumeration type in upper case, so:

enum aarch64_calling_abi
{
  AARCH64_CALLING_ABI_EABI,
  AARCH64_CALLING_ABI_MS
};

or something very much like that.

R.

Re: [PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

[Richard Earnshaw (lists)]

On 21/02/2024 18:30, Evgeny Karpov wrote:
> 
+/* X18 reserved for the TEB on Windows.  */
+#ifdef TARGET_ARM64_MS_ABI
+# define FIXED_X18 1
+# define CALL_USED_X18 0
+#else
+# define FIXED_X18 0
+# define CALL_USED_X18 1
+#endif

I'm not overly keen on ifdefs like this (and the one below), it can get quite confusing if we have to support more than a couple of ABIs.  Perhaps we could create a couple of new headers, one for the EABI (which all existing targets would then need to include) and one for the MS ABI.  Then the mingw port would use that instead of the EABI header.

An alternative is to make all this dynamic, based on the setting of the aarch64_calling_abi enum and to make the adjustments in aarch64_conditional_register_usage.

+# define CALL_USED_X18 0

Is that really correct?  If the register is really reserved, but some code modifies it anyway, this will cause the compiler to restore the old value at the end of a function; generally, for a reserved register, code that knows what it's doing would want to make permanent changes to this value.

+#ifdef TARGET_ARM64_MS_ABI
+# define STATIC_CHAIN_REGNUM		R17_REGNUM
+#else
+# define STATIC_CHAIN_REGNUM		R18_REGNUM
+#endif

If we went the enum way, we'd want something like

#define STATIC_CHAIN_REGNUM (calling_abi == AARCH64_CALLING_ABI_MS ? R17_REGNUM : R18_REGNUM)

R.

Re: [PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

[Richard Earnshaw (lists)]

On 21/02/2024 18:30, Evgeny Karpov wrote:
> 
+	tm_defines="${tm_defines} TARGET_ARM64_MS_ABI=1"

I missed this on first reading...

The GCC port name uses AARCH64, please use that internally rather than other names.  The only time when we should be using ARM64 is when it's needed for compatibility with other compilers and that doesn't apply here AFAICT.

R.

Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[Richard Earnshaw (lists)]

On 21/02/2024 18:36, Evgeny Karpov wrote:
> 
+/* GNU as supports weak symbols on PECOFF.  */
+#ifdef HAVE_GAS_WEAK

Can't we assume this is true?  It was most likely needed on i386 because support goes back longer than the assembler had this feature, but it looks like it was added in 2000, or thereabouts, so significantly before aarch64 was supported in the assembler.

+#ifndef HAVE_GAS_ALIGNED_COMM

And this was added to GCC in 2009, which probably means it predates aarch64-coff support in gas as well.

R.

Re: [PATCH v1 10/13] Rename "x86 Windows Options" to "Cygwin and MinGW Options"

[Richard Earnshaw (lists)]

On 21/02/2024 18:38, Evgeny Karpov wrote:
> 
For this change you might want to put some form of re-direct in the manual under the old name so that anybody used to looking for the old entry will know where things have been moved to.  Something like

x86 Windows Options
  See xref(Cygwin and MinGW Options).

R.

Re: [PATCH v1 13/13] Add aarch64-w64-mingw32 target to libgcc

[Richard Earnshaw (lists)]

On 21/02/2024 18:40, Evgeny Karpov wrote:
> 
+aarch64-*-mingw*)

This doesn't match the glob pattern you added to config.gcc in an earlier patch, but see my comment on that.  The two should really be consistent with each other or you might get build failures late on.

R.

Re: [PATCH v1 00/13] Add aarch64-w64-mingw32 target

[Richard Earnshaw (lists)]

On 21/02/2024 17:47, Evgeny Karpov wrote:
> Hello,
> 
> We would like to take your attention to the review of changes for the
> new GCC target, aarch64-w64-mingw32. The new target will be
> supported, tested, added to CI, and maintained by Linaro. This marks
> the first of three planned patch series contributing to the GCC C
> compiler's support for Windows Arm64.
> 
> 1. Minimal aarch64-w64-mingw32 C implementation to cross-compile
> hello-world with libgcc for Windows Arm64 using MinGW.
> 2. Extension of the aarch64-w64-mingw32 C implementation to
> cross-compile OpenSSL, OpenBLAS, FFmpeg, and libjpeg-turbo. All
> packages successfully pass tests.
> 3. Addition of call stack support for debugging, resolution of
> optimization issues in the C compiler, and DLL export/import for the
> aarch64-w64-mingw32 target.
> 
> This patch series introduces the 1st point, which involves building
> hello-world for the aarch64-w64-mingw32 target. The patch depends on
> the binutils changes for the aarch64-w64-mingw32 target that have
> already been merged.
> 
> The binutils should include recent relocation fixes.
> f87eaf8ff3995a5888c6dc4996a20c770e6bcd36
> aarch64: Add new relocations and limit COFF AArch64 relocation offsets
> 
> The series is structured in a way to trivially show that it should not
> affect any other targets.
> 
> In this patch, several changes have been made to support the
> aarch64-w64-mingw32 target for GCC. The modifications include the
> definition of the MS ABI for aarch64, adjustments to FIXED_REGISTERS
> and STATIC_CHAIN_REGNUM for different ABIs, and specific definitions
> for COFF format on AArch64. Additionally, the patch reuses MinGW
> <stdint.h> types and definitions from i386, relocating them to a new
> mingw folder for shared usage between both targets.
> 
> MinGW-specific options have been introduced for AArch64, along with
> override options for aarch64-w64-mingw32. Builtin stack probing for
> override options for aarch64-w64-mingw32. Builtin stack probing for
> AArch64 has been enabled as an alternative for chkstk. Symbol name
> encoding and section information handling for aarch64-w64-mingw32 have
> been incorporated, and the MinGW environment has been added, which
> will also be utilized for defining the Cygwin environment in the
> future.
> 
> The patch includes renaming "x86 Windows Options" to "Cygwin and MinGW
> Options," which now encompasses AArch64 as well. AArch64-specific
> Cygwin and MinGW Options have been introduced for the unique
> requirements of the AArch64 architecture.
> 
> Function type declaration and named sections support have been added.
> The necessary objects for Cygwin and MinGW have been built for the
> aarch64-w64-mingw32 target, and relevant files such as msformat-c.cc
> and winnt-d.cc have been moved to the mingw folder for reuse in
> AArch64.
> 
> Furthermore, the aarch64-w64-mingw32 target has been included in both
> libatomic and libgcc, ensuring support for the AArch64 architecture
> within these libraries. These changes collectively enhance the
> capabilities of GCC for the specified target.
> 
> Coauthors: Zac Walker <zacwalker@microsoft.com>,
> Mark Harmstone <mark@harmstone.com>  and
> Ron Riddle <ron.riddle@microsoft.com>
> 
> Refactored, prepared, and validated by 
> Radek Barton <radek.barton@microsoft.com> and 
> Evgeny Karpov <evgeny.karpov@microsoft.com>
> 
> Special thanks to the Linaro GNU toolchain team for internal review
> and assistance in preparing the patch series!
> 
> Regards,
> Evgeny

Thanks for posting this.

I've only read quickly through this patch series and responded where I think some action is obviously required.  That doesn't necessarily mean the other patches are perfect, though, just that nothing immediately caught my attention.

R.

> 
> 
> Zac Walker (13):
>   Introduce aarch64-w64-mingw32 target
>   aarch64: The aarch64-w64-mingw32 target implements the MS ABI
>   aarch64: Mark x18 register as a fixed register for MS ABI
>   aarch64: Add aarch64-w64-mingw32 COFF
>   Reuse MinGW from i386 for AArch64
>   Rename section and encoding functions from i386 which will be used in
>     aarch64
>   Exclude i386 functionality from aarch64 build
>   aarch64: Add Cygwin and MinGW environments for AArch64
>   aarch64: Add SEH to machine_function
>   Rename "x86 Windows Options" to "Cygwin and MinGW Options"
>   aarch64: Build and add objects for Cygwin and MinGW for AArch64
>   aarch64: Add aarch64-w64-mingw32 target to libatomic
>   Add aarch64-w64-mingw32 target to libgcc
> 
>  fixincludes/mkfixinc.sh                       |   3 +-
>  gcc/config.gcc                                |  47 +++--
>  gcc/config/aarch64/aarch64-coff.h             |  92 +++++++++
>  gcc/config/aarch64/aarch64-opts.h             |   7 +
>  gcc/config/aarch64/aarch64-protos.h           |   5 +
>  gcc/config/aarch64/aarch64.h                  |  25 ++-
>  gcc/config/aarch64/cygming.h                  | 178 ++++++++++++++++++
>  gcc/config/i386/cygming.h                     |  18 +-
>  gcc/config/i386/cygming.opt.urls              |  30 ---
>  gcc/config/i386/i386-protos.h                 |  12 +-
>  gcc/config/i386/mingw-w64.opt.urls            |   2 +-
>  gcc/config/lynx.opt.urls                      |   2 +-
>  gcc/config/{i386 => mingw}/cygming.opt        |   0
>  gcc/config/mingw/cygming.opt.urls             |  30 +++
>  gcc/config/{i386 => mingw}/cygwin-d.cc        |   0
>  gcc/config/{i386 => mingw}/mingw-stdint.h     |   0
>  gcc/config/{i386 => mingw}/mingw.opt          |   0
>  gcc/config/{i386 => mingw}/mingw.opt.urls     |   2 +-
>  gcc/config/{i386 => mingw}/mingw32.h          |   0
>  gcc/config/{i386 => mingw}/msformat-c.cc      |   0
>  gcc/config/{i386 => mingw}/t-cygming          |  23 ++-
>  gcc/config/{i386 => mingw}/winnt-cxx.cc       |   0
>  gcc/config/{i386 => mingw}/winnt-d.cc         |   0
>  gcc/config/{i386 => mingw}/winnt-stubs.cc     |   0
>  gcc/config/{i386 => mingw}/winnt.cc           |  30 +--
>  gcc/doc/invoke.texi                           |  12 +-
>  gcc/varasm.cc                                 |   2 +-
>  libatomic/configure.tgt                       |   2 +-
>  libgcc/config.host                            |  23 ++-
>  libgcc/config/aarch64/t-no-eh                 |   2 +
>  libgcc/config/{i386 => mingw}/t-gthr-win32    |   0
>  libgcc/config/{i386 => mingw}/t-mingw-pthread |   0
>  32 files changed, 450 insertions(+), 97 deletions(-)
>  create mode 100644 gcc/config/aarch64/aarch64-coff.h
>  create mode 100644 gcc/config/aarch64/cygming.h
>  delete mode 100644 gcc/config/i386/cygming.opt.urls
>  rename gcc/config/{i386 => mingw}/cygming.opt (100%)
>  create mode 100644 gcc/config/mingw/cygming.opt.urls
>  rename gcc/config/{i386 => mingw}/cygwin-d.cc (100%)
>  rename gcc/config/{i386 => mingw}/mingw-stdint.h (100%)
>  rename gcc/config/{i386 => mingw}/mingw.opt (100%)
>  rename gcc/config/{i386 => mingw}/mingw.opt.urls (86%)
>  rename gcc/config/{i386 => mingw}/mingw32.h (100%)
>  rename gcc/config/{i386 => mingw}/msformat-c.cc (100%)
>  rename gcc/config/{i386 => mingw}/t-cygming (73%)
>  rename gcc/config/{i386 => mingw}/winnt-cxx.cc (100%)
>  rename gcc/config/{i386 => mingw}/winnt-d.cc (100%)
>  rename gcc/config/{i386 => mingw}/winnt-stubs.cc (100%)
>  rename gcc/config/{i386 => mingw}/winnt.cc (97%)
>  create mode 100644 libgcc/config/aarch64/t-no-eh
>  rename libgcc/config/{i386 => mingw}/t-gthr-win32 (100%)
>  rename libgcc/config/{i386 => mingw}/t-mingw-pthread (100%)
> 

RE: [EXTERNAL] Re: [PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

[Evgeny Karpov]

Hi Richard,

Thanks for the review!

TARGET_ARM64_MS_ABI refers to the official Microsoft ARM64 ABI naming used for the target. 
If AARCH64 is a more preferred name, it will be changed in PATCH v2.

https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170

Regards,
Evgeny

-----Original Message-----
Thursday, February 22, 2024 2:11 PM
Richard Earnshaw (lists) wrote:

On 21/02/2024 18:30, Evgeny Karpov wrote:
>
+       tm_defines="${tm_defines} TARGET_ARM64_MS_ABI=1"

I missed this on first reading...

The GCC port name uses AARCH64, please use that internally rather than other names.  The only time when we should be using ARM64 is when it's needed for compatibility with other compilers and that doesn't apply here AFAICT.

R.

[PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[Evgeny Karpov]

Hello Andrew,

Thank you for the review!

Renaming functions and comments that reference functions with the
i386_ prefix can trigger extensive changes. This task should
ideally be handled in a separate follow-up patch.

The primary goal of the renaming changes in
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20240221/8f41fb9a/attachment-0001.txt 
was to avoid direct references from the aarch64 target to 
functions with i386_ prefix.

Regards,
Evgeny

-----Original Message-----
Wednesday, February 21, 2024 7:50 PM
Andrew Pinski wrote:

On Wed, Feb 21, 2024 at 10:38 AM Evgeny Karpov <Evgeny.Karpov@microsoft.com> wrote:
>
>

In config/i386/winnt.cc there are many x86_64 comments and many function names that use i386 in them? When moving it seems like better to rename them and remove references to 86.
I don't see any changes that rename the functions or comments there.

Thanks,
Andrew

[PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[Evgeny Karpov]

A ChangeLog template using "Moved... ...here" has been generated by contrib/mklog.py.
It seems that it needs modification.

Regards,
Evgeny

-----Original Message-----
Thursday, February 22, 2024 12:11 PM
Richard Earnshaw (lists) wrote:

> The ChangeLog has to be expressed in present tense, as mandated by the standard; s/Moved/Move/g etc.

Agreed, but that's a detail that we can get to once the patch has been properly reviewed.

Re: [PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

[Andrew Pinski]

On Thu, Feb 22, 2024 at 3:56 AM Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> On 21/02/2024 18:30, Evgeny Karpov wrote:
> >
> +/* X18 reserved for the TEB on Windows.  */
> +#ifdef TARGET_ARM64_MS_ABI
> +# define FIXED_X18 1
> +# define CALL_USED_X18 0
> +#else
> +# define FIXED_X18 0
> +# define CALL_USED_X18 1
> +#endif
>
> I'm not overly keen on ifdefs like this (and the one below), it can get quite confusing if we have to support more than a couple of ABIs.  Perhaps we could create a couple of new headers, one for the EABI (which all existing targets would then need to include) and one for the MS ABI.  Then the mingw port would use that instead of the EABI header.
>
> An alternative is to make all this dynamic, based on the setting of the aarch64_calling_abi enum and to make the adjustments in aarch64_conditional_register_usage.

Dynamically might be needed also if we want to support ms_abi
attribute and/or -mabi=ms to support the wine folks.

Thanks,
Andrew Pinski

>
> +# define CALL_USED_X18 0
>
> Is that really correct?  If the register is really reserved, but some code modifies it anyway, this will cause the compiler to restore the old value at the end of a function; generally, for a reserved register, code that knows what it's doing would want to make permanent changes to this value.
>
> +#ifdef TARGET_ARM64_MS_ABI
> +# define STATIC_CHAIN_REGNUM           R17_REGNUM
> +#else
> +# define STATIC_CHAIN_REGNUM           R18_REGNUM
> +#endif
>
> If we went the enum way, we'd want something like
>
> #define STATIC_CHAIN_REGNUM (calling_abi == AARCH64_CALLING_ABI_MS ? R17_REGNUM : R18_REGNUM)
>
> R.

Re: [PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[Joseph Myers]

On Thu, 22 Feb 2024, Richard Earnshaw (lists) wrote:

> On 21/02/2024 21:34, rep.dot.nop@gmail.com wrote:
> > On 21 February 2024 19:34:43 CET, Evgeny Karpov <Evgeny.Karpov@microsoft.com> wrote:
> >>
> > 
> > Please use git send-email. Your mail ends up as empty as here, otherwise.
> 
> I don't see anything wrong with it; niether does patchwork 
> (https://patchwork.sourceware.org/project/gcc/list/?series=31191) nor 
> does the Linaro CI bot.  So perhaps it's your mailer that's 
> misconfigured.

The first part of the multipart/mixed message is empty (well, two blank 
lines).  The second part, the patch, has Content-Disposition: attachment, 
so it's correct for a mailer not to show it inline (instead showing an 
empty message with an attachment - which is how it appeared to me).

-- 
Joseph S. Myers
josmyers@redhat.com

Re: [PATCH v1 00/13] Add aarch64-w64-mingw32 target

[Mark Harmstone]

Hi all,

Seems to work for me! Nice work.

It also works nicely with EFI as well, for anyone interested:

test.c:

#include <efi.h>

EFI_STATUS efi_main(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE* SystemTable) {
     SystemTable->ConOut->OutputString(SystemTable->ConOut, L"hello, world\r\n");

     return EFI_SUCCESS;
}

$ aarch64-w64-mingw32-gcc -I/usr/include/efi -nostartfiles -Wl,--subsystem,10 -eefi_main test.c -o test.efi

Mark

On 21/2/24 17:47, Evgeny Karpov wrote:
> Hello,
> 
> We would like to take your attention to the review of changes for the
> new GCC target, aarch64-w64-mingw32. The new target will be
> supported, tested, added to CI, and maintained by Linaro. This marks
> the first of three planned patch series contributing to the GCC C
> compiler's support for Windows Arm64.
> 
> 1. Minimal aarch64-w64-mingw32 C implementation to cross-compile
> hello-world with libgcc for Windows Arm64 using MinGW.
> 2. Extension of the aarch64-w64-mingw32 C implementation to
> cross-compile OpenSSL, OpenBLAS, FFmpeg, and libjpeg-turbo. All
> packages successfully pass tests.
> 3. Addition of call stack support for debugging, resolution of
> optimization issues in the C compiler, and DLL export/import for the
> aarch64-w64-mingw32 target.
> 
> This patch series introduces the 1st point, which involves building
> hello-world for the aarch64-w64-mingw32 target. The patch depends on
> the binutils changes for the aarch64-w64-mingw32 target that have
> already been merged.
> 
> The binutils should include recent relocation fixes.
> f87eaf8ff3995a5888c6dc4996a20c770e6bcd36
> aarch64: Add new relocations and limit COFF AArch64 relocation offsets
> 
> The series is structured in a way to trivially show that it should not
> affect any other targets.
> 
> In this patch, several changes have been made to support the
> aarch64-w64-mingw32 target for GCC. The modifications include the
> definition of the MS ABI for aarch64, adjustments to FIXED_REGISTERS
> and STATIC_CHAIN_REGNUM for different ABIs, and specific definitions
> for COFF format on AArch64. Additionally, the patch reuses MinGW
> <stdint.h> types and definitions from i386, relocating them to a new
> mingw folder for shared usage between both targets.
> 
> MinGW-specific options have been introduced for AArch64, along with
> override options for aarch64-w64-mingw32. Builtin stack probing for
> override options for aarch64-w64-mingw32. Builtin stack probing for
> AArch64 has been enabled as an alternative for chkstk. Symbol name
> encoding and section information handling for aarch64-w64-mingw32 have
> been incorporated, and the MinGW environment has been added, which
> will also be utilized for defining the Cygwin environment in the
> future.
> 
> The patch includes renaming "x86 Windows Options" to "Cygwin and MinGW
> Options," which now encompasses AArch64 as well. AArch64-specific
> Cygwin and MinGW Options have been introduced for the unique
> requirements of the AArch64 architecture.
> 
> Function type declaration and named sections support have been added.
> The necessary objects for Cygwin and MinGW have been built for the
> aarch64-w64-mingw32 target, and relevant files such as msformat-c.cc
> and winnt-d.cc have been moved to the mingw folder for reuse in
> AArch64.
> 
> Furthermore, the aarch64-w64-mingw32 target has been included in both
> libatomic and libgcc, ensuring support for the AArch64 architecture
> within these libraries. These changes collectively enhance the
> capabilities of GCC for the specified target.
> 
> Coauthors: Zac Walker <zacwalker@microsoft.com>,
> Mark Harmstone <mark@harmstone.com>  and
> Ron Riddle <ron.riddle@microsoft.com>
> 
> Refactored, prepared, and validated by
> Radek Barton <radek.barton@microsoft.com> and
> Evgeny Karpov <evgeny.karpov@microsoft.com>
> 
> Special thanks to the Linaro GNU toolchain team for internal review
> and assistance in preparing the patch series!
> 
> Regards,
> Evgeny
> 
> 
> Zac Walker (13):
>    Introduce aarch64-w64-mingw32 target
>    aarch64: The aarch64-w64-mingw32 target implements the MS ABI
>    aarch64: Mark x18 register as a fixed register for MS ABI
>    aarch64: Add aarch64-w64-mingw32 COFF
>    Reuse MinGW from i386 for AArch64
>    Rename section and encoding functions from i386 which will be used in
>      aarch64
>    Exclude i386 functionality from aarch64 build
>    aarch64: Add Cygwin and MinGW environments for AArch64
>    aarch64: Add SEH to machine_function
>    Rename "x86 Windows Options" to "Cygwin and MinGW Options"
>    aarch64: Build and add objects for Cygwin and MinGW for AArch64
>    aarch64: Add aarch64-w64-mingw32 target to libatomic
>    Add aarch64-w64-mingw32 target to libgcc
> 
>   fixincludes/mkfixinc.sh                       |   3 +-
>   gcc/config.gcc                                |  47 +++--
>   gcc/config/aarch64/aarch64-coff.h             |  92 +++++++++
>   gcc/config/aarch64/aarch64-opts.h             |   7 +
>   gcc/config/aarch64/aarch64-protos.h           |   5 +
>   gcc/config/aarch64/aarch64.h                  |  25 ++-
>   gcc/config/aarch64/cygming.h                  | 178 ++++++++++++++++++
>   gcc/config/i386/cygming.h                     |  18 +-
>   gcc/config/i386/cygming.opt.urls              |  30 ---
>   gcc/config/i386/i386-protos.h                 |  12 +-
>   gcc/config/i386/mingw-w64.opt.urls            |   2 +-
>   gcc/config/lynx.opt.urls                      |   2 +-
>   gcc/config/{i386 => mingw}/cygming.opt        |   0
>   gcc/config/mingw/cygming.opt.urls             |  30 +++
>   gcc/config/{i386 => mingw}/cygwin-d.cc        |   0
>   gcc/config/{i386 => mingw}/mingw-stdint.h     |   0
>   gcc/config/{i386 => mingw}/mingw.opt          |   0
>   gcc/config/{i386 => mingw}/mingw.opt.urls     |   2 +-
>   gcc/config/{i386 => mingw}/mingw32.h          |   0
>   gcc/config/{i386 => mingw}/msformat-c.cc      |   0
>   gcc/config/{i386 => mingw}/t-cygming          |  23 ++-
>   gcc/config/{i386 => mingw}/winnt-cxx.cc       |   0
>   gcc/config/{i386 => mingw}/winnt-d.cc         |   0
>   gcc/config/{i386 => mingw}/winnt-stubs.cc     |   0
>   gcc/config/{i386 => mingw}/winnt.cc           |  30 +--
>   gcc/doc/invoke.texi                           |  12 +-
>   gcc/varasm.cc                                 |   2 +-
>   libatomic/configure.tgt                       |   2 +-
>   libgcc/config.host                            |  23 ++-
>   libgcc/config/aarch64/t-no-eh                 |   2 +
>   libgcc/config/{i386 => mingw}/t-gthr-win32    |   0
>   libgcc/config/{i386 => mingw}/t-mingw-pthread |   0
>   32 files changed, 450 insertions(+), 97 deletions(-)
>   create mode 100644 gcc/config/aarch64/aarch64-coff.h
>   create mode 100644 gcc/config/aarch64/cygming.h
>   delete mode 100644 gcc/config/i386/cygming.opt.urls
>   rename gcc/config/{i386 => mingw}/cygming.opt (100%)
>   create mode 100644 gcc/config/mingw/cygming.opt.urls
>   rename gcc/config/{i386 => mingw}/cygwin-d.cc (100%)
>   rename gcc/config/{i386 => mingw}/mingw-stdint.h (100%)
>   rename gcc/config/{i386 => mingw}/mingw.opt (100%)
>   rename gcc/config/{i386 => mingw}/mingw.opt.urls (86%)
>   rename gcc/config/{i386 => mingw}/mingw32.h (100%)
>   rename gcc/config/{i386 => mingw}/msformat-c.cc (100%)
>   rename gcc/config/{i386 => mingw}/t-cygming (73%)
>   rename gcc/config/{i386 => mingw}/winnt-cxx.cc (100%)
>   rename gcc/config/{i386 => mingw}/winnt-d.cc (100%)
>   rename gcc/config/{i386 => mingw}/winnt-stubs.cc (100%)
>   rename gcc/config/{i386 => mingw}/winnt.cc (97%)
>   create mode 100644 libgcc/config/aarch64/t-no-eh
>   rename libgcc/config/{i386 => mingw}/t-gthr-win32 (100%)
>   rename libgcc/config/{i386 => mingw}/t-mingw-pthread (100%)
> 

Re: [PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

[Iain Sandoe]

> On 22 Feb 2024, at 17:45, Andrew Pinski <pinskia@gmail.com> wrote:
> 
> On Thu, Feb 22, 2024 at 3:56 AM Richard Earnshaw (lists)
> <Richard.Earnshaw@arm.com> wrote:
>> 
>> On 21/02/2024 18:30, Evgeny Karpov wrote:
>>> 
>> +/* X18 reserved for the TEB on Windows.  */
>> +#ifdef TARGET_ARM64_MS_ABI
>> +# define FIXED_X18 1
>> +# define CALL_USED_X18 0
>> +#else
>> +# define FIXED_X18 0
>> +# define CALL_USED_X18 1
>> +#endif
>> 
>> I'm not overly keen on ifdefs like this (and the one below), it can get quite confusing if we have to support more than a couple of ABIs.  Perhaps we could create a couple of new headers, one for the EABI (which all existing targets would then need to include) and one for the MS ABI.  Then the mingw port would use that instead of the EABI header.
>> 
>> An alternative is to make all this dynamic, based on the setting of the aarch64_calling_abi enum and to make the adjustments in aarch64_conditional_register_usage.
> 
> Dynamically might be needed also if we want to support ms_abi
> attribute and/or -mabi=ms to support the wine folks.

X18 is also reserved on Darwin - in my current branch I have it non-dynamic too.
Iain

> 
> Thanks,
> Andrew Pinski
> 
>> 
>> +# define CALL_USED_X18 0
>> 
>> Is that really correct?  If the register is really reserved, but some code modifies it anyway, this will cause the compiler to restore the old value at the end of a function; generally, for a reserved register, code that knows what it's doing would want to make permanent changes to this value.
>> 
>> +#ifdef TARGET_ARM64_MS_ABI
>> +# define STATIC_CHAIN_REGNUM           R17_REGNUM
>> +#else
>> +# define STATIC_CHAIN_REGNUM           R18_REGNUM
>> +#endif
>> 
>> If we went the enum way, we'd want something like
>> 
>> #define STATIC_CHAIN_REGNUM (calling_abi == AARCH64_CALLING_ABI_MS ? R17_REGNUM : R18_REGNUM)
>> 
>> R.

[PATCH v1 00/13] Add aarch64-w64-mingw32 target

[Evgeny Karpov]

Hi Maxim,

Thank you for the review and the test build!

Regards,
Evgeny

-----Original Message-----
Wednesday, February 21, 2024 7:27 PM 
Maxim Kuvyrkov wrote:

Hi Evgeny,

Great job!

For reference, here is a test build of this patch series using Linaro Toolchain CI: 
https://ci.linaro.org/view/tcwg-build/job/tcwg_gnu_mingw_build--master-woa64-build/9/artifact/artifacts/

--
Maxim Kuvyrkov
 

[PATCH v1 00/13] Add aarch64-w64-mingw32 target

[Evgeny Karpov]

Hi Mark,

Thanks for testing the patch series!
It is great to know that EFI also works well.

Thank you for your contribution to this work!

Regards,
Evgeny

-----Original Message-----
Thursday, February 22, 2024 7:11 PM 
Mark Harmstone wrote:

Hi all,

Seems to work for me! Nice work.

It also works nicely with EFI as well, for anyone interested:

test.c:

#include <efi.h>

EFI_STATUS efi_main(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE* SystemTable) {
     SystemTable->ConOut->OutputString(SystemTable->ConOut, L"hello, world\r\n");

     return EFI_SUCCESS;
}

$ aarch64-w64-mingw32-gcc -I/usr/include/efi -nostartfiles -Wl,--subsystem,10 -eefi_main test.c -o test.efi

Mark

[PATCH v1 01/13] Introduce aarch64-w64-mingw32 target

[Evgeny Karpov]

Hi Andrew and Richard,

Thank you for pointing out there's no need for a 64-bit ISA and the big-endian target.
These changes will be addressed in v2.

Regards,
Evgeny

-----Original Message-----
Thursday, February 22, 2024 12:33 PM 
Richard Earnshaw (lists)  wrote:
>
+aarch64*-*-mingw*)

Other targets are a bit inconsistent here as well, but, as Andrew mentioned, if you don't want to handle big-endian, it might be better to match aarch64-*-mingw* here.


-----Original Message-----
Wednesday, February 21, 2024 7:23 PM 
Andrew Pinski wrote:

> need_64bit_isa=yes

This is not needed in the patch as it is only used for x86_64 targets.

Should you make sure nobody specifies the big-endian target:
aarch64_be-w64-mingw32  ?

[PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements

[Evgeny Karpov]

The calling ABI enum definition has been done following a similar convention in 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-opts.h;h=ef2825803b32001b9632769bdff196d1e43d27ba;hb=refs/heads/master#l41

MS_ABI is used in gcc/config/i386/mingw32.h and gcc/config/i386/winnt-d.cc
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/mingw32.h;h=58304fc55f629648e47490fd3c0f3db3858e4fd8;hb=refs/heads/master#l22

These files are moved to the mingw folder in the patch series.
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20240221/5e75c464/attachment.txt

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
+};
+

Regards,
Evgeny


Thursday, February 22, 2024 12:40 PM
Richard Earnshaw (lists) wrote:

>
+/* Available call ABIs.  */
+enum calling_abi
+{
+  AARCH64_EABI = 0,
+  MS_ABI = 1
+};
+

The convention in this file seems to be that all enum types to start with aarch64.  Also, the enumeration values should start with the name of the enumeration type in upper case, so:

enum aarch64_calling_abi
{
  AARCH64_CALLING_ABI_EABI,
  AARCH64_CALLING_ABI_MS
};

or something very much like that.

R.

Re: [PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

[Jacek Caban]

On 22.02.2024 18:45, Andrew Pinski wrote:
> On Thu, Feb 22, 2024 at 3:56 AM Richard Earnshaw (lists)
> <Richard.Earnshaw@arm.com> wrote:
>> On 21/02/2024 18:30, Evgeny Karpov wrote:
>> +/* X18 reserved for the TEB on Windows.  */
>> +#ifdef TARGET_ARM64_MS_ABI
>> +# define FIXED_X18 1
>> +# define CALL_USED_X18 0
>> +#else
>> +# define FIXED_X18 0
>> +# define CALL_USED_X18 1
>> +#endif
>>
>> I'm not overly keen on ifdefs like this (and the one below), it can get quite confusing if we have to support more than a couple of ABIs.  Perhaps we could create a couple of new headers, one for the EABI (which all existing targets would then need to include) and one for the MS ABI.  Then the mingw port would use that instead of the EABI header.
>>
>> An alternative is to make all this dynamic, based on the setting of the aarch64_calling_abi enum and to make the adjustments in aarch64_conditional_register_usage.
> Dynamically might be needed also if we want to support ms_abi
> attribute and/or -mabi=ms to support the wine folks.


Wine no longer needs ms_abi, it was needed for PE-in-ELF modules in the 
past. We use use proper PE files now, so we need a cross compiler, but 
no special attributes. aarch64-w64-mingw32 is already well supported by 
Wine when using llvm-mingw, so as soon as GCC properly supports the ABI, 
Wine should just work with it, in theory. I didn't try it, but I don't 
see things like vararg support in this patchset nor in the repo, so I 
assume it won't work yet.


Thanks for the work!

Jacek

Re: [PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

[Richard Sandiford]

"Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com> writes:
> On 21/02/2024 18:30, Evgeny Karpov wrote:
>> 
> +/* X18 reserved for the TEB on Windows.  */
> +#ifdef TARGET_ARM64_MS_ABI
> +# define FIXED_X18 1
> +# define CALL_USED_X18 0
> +#else
> +# define FIXED_X18 0
> +# define CALL_USED_X18 1
> +#endif
>
> I'm not overly keen on ifdefs like this (and the one below), it can get quite confusing if we have to support more than a couple of ABIs.  Perhaps we could create a couple of new headers, one for the EABI (which all existing targets would then need to include) and one for the MS ABI.  Then the mingw port would use that instead of the EABI header.
>
> An alternative is to make all this dynamic, based on the setting of the aarch64_calling_abi enum and to make the adjustments in aarch64_conditional_register_usage.

Agreed FWIW.

> +# define CALL_USED_X18 0
>
> Is that really correct?  If the register is really reserved, but some code modifies it anyway, this will cause the compiler to restore the old value at the end of a function; generally, for a reserved register, code that knows what it's doing would want to make permanent changes to this value.

I don't think it would do that for fixed registers.  For those this
is more whether calls are allowed to change the value of x18 or whether
x18 is supposed to remain fixed (e.g. set at the start of the thread and
not changed thereafter).

How does the MS ABI use this register?  Same question for Darwin I suppose.

Thanks,
Richard

>
> +#ifdef TARGET_ARM64_MS_ABI
> +# define STATIC_CHAIN_REGNUM		R17_REGNUM
> +#else
> +# define STATIC_CHAIN_REGNUM		R18_REGNUM
> +#endif
>
> If we went the enum way, we'd want something like
>
> #define STATIC_CHAIN_REGNUM (calling_abi == AARCH64_CALLING_ABI_MS ? R17_REGNUM : R18_REGNUM)
>
> R.

Re: [PATCH v1 04/13] aarch64: Add aarch64-w64-mingw32 COFF

[Richard Sandiford]

Evgeny Karpov <Evgeny.Karpov@microsoft.com> writes:
> From 55fd2a63afa9abb3543d714b6f5925efd2682e08 Mon Sep 17 00:00:00 2001
> From: Zac Walker <zacwalker@microsoft.com>
> Date: Wed, 21 Feb 2024 12:20:46 +0100
> Subject: [PATCH v1 04/13] aarch64: Add aarch64-w64-mingw32 COFF
>
> Define ASM specific for COFF format on AArch64.
>
> gcc/ChangeLog:
>
> 	* config.gcc: Add COFF format support definitions.
> 	* config/aarch64/aarch64-coff.h: New file.

The only surprising thing here to me was:

> ---
>  gcc/config.gcc                    |  1 +
>  gcc/config/aarch64/aarch64-coff.h | 92 +++++++++++++++++++++++++++++++
>  2 files changed, 93 insertions(+)
>  create mode 100644 gcc/config/aarch64/aarch64-coff.h
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 2a9e4c44f50..34c7be72fb6 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -1264,6 +1264,7 @@ aarch64*-*-linux*)
>  	TM_MULTILIB_CONFIG=`echo $TM_MULTILIB_CONFIG | sed 's/^,//'`
>  	;;
>  aarch64*-*-mingw*)
> +	tm_file="${tm_file} aarch64/aarch64-coff.h"
>  	tmake_file="${tmake_file} aarch64/t-aarch64"
>  	case ${enable_threads} in
>  	  "" | yes | win32)
> diff --git a/gcc/config/aarch64/aarch64-coff.h b/gcc/config/aarch64/aarch64-coff.h
> new file mode 100644
> index 00000000000..d91bc36b67b
> --- /dev/null
> +++ b/gcc/config/aarch64/aarch64-coff.h
> @@ -0,0 +1,92 @@
> +/* Machine description for AArch64 architecture.
> +   Copyright (C) 2024 Free Software Foundation, Inc.
> +
> +   This file is part of GCC.
> +
> +   GCC is free software; you can redistribute it and/or modify it
> +   under the terms of the GNU General Public License as published by
> +   the Free Software Foundation; either version 3, or (at your option)
> +   any later version.
> +
> +   GCC is distributed in the hope that it will be useful, but
> +   WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   General Public License for more details.
> +
> +   You should have received a copy of the GNU General Public License
> +   along with GCC; see the file COPYING3.  If not see
> +   <http://www.gnu.org/licenses/>.  */
> +
> +#ifndef GCC_AARCH64_COFF_H
> +#define GCC_AARCH64_COFF_H
> +
> +#include "aarch64.h"
> +
> +#ifndef LOCAL_LABEL_PREFIX
> +# define LOCAL_LABEL_PREFIX 	""
> +#endif
> +
> +/* Using long long breaks -ansi and -std=c90, so these will need to be
> +   made conditional for an LLP64 ABI.  */
> +#undef SIZE_TYPE
> +#define SIZE_TYPE	"long long unsigned int"
> +
> +#undef PTRDIFF_TYPE
> +#define PTRDIFF_TYPE	"long long int"
> +
> +#define TARGET_64BIT 1

...this.  Does some code that is shared between x86 and aarch64 rely
on this definition?  It might be worth identifying the code in a comment
if so.

Thanks,
Richard

> +#undef LONG_TYPE_SIZE
> +#define LONG_TYPE_SIZE 32
> +
> +#ifndef ASM_GENERATE_INTERNAL_LABEL
> +# define ASM_GENERATE_INTERNAL_LABEL(STRING, PREFIX, NUM)  \
> +  sprintf (STRING, "*%s%s%u", LOCAL_LABEL_PREFIX, PREFIX, (unsigned int)(NUM))
> +#endif
> +
> +#define ASM_OUTPUT_ALIGN(STREAM, POWER)		\
> +  fprintf (STREAM, "\t.align\t%d\n", (int)POWER)
> +
> +/* Output a common block.  */
> +#ifndef ASM_OUTPUT_COMMON
> +# define ASM_OUTPUT_COMMON(STREAM, NAME, SIZE, ROUNDED)	\
> +    {							\
> +      fprintf (STREAM, "\t.comm\t");			\
> +      assemble_name (STREAM, NAME);			\
> +      asm_fprintf (STREAM, ", %d, %d\n", 		\
> +      (int)(ROUNDED), (int)(SIZE));	\
> +    }
> +#endif
> +
> +/* Output a local common block.  /bin/as can't do this, so hack a
> +   `.space' into the bss segment.  Note that this is *bad* practice,
> +   which is guaranteed NOT to work since it doesn't define STATIC
> +   COMMON space but merely STATIC BSS space.  */
> +#ifndef ASM_OUTPUT_ALIGNED_LOCAL
> +# define ASM_OUTPUT_ALIGNED_LOCAL(STREAM, NAME, SIZE, ALIGN)		\
> +    {									\
> +      switch_to_section (bss_section);					\
> +      ASM_OUTPUT_ALIGN (STREAM, floor_log2 (ALIGN / BITS_PER_UNIT));	\
> +      ASM_OUTPUT_LABEL (STREAM, NAME);					\
> +      fprintf (STREAM, "\t.space\t%d\n", (int)(SIZE));			\
> +    }
> +#endif
> +
> +#define ASM_OUTPUT_SKIP(STREAM, NBYTES) 	\
> +  fprintf (STREAM, "\t.space\t%d  // skip\n", (int) (NBYTES))
> +
> +#define ASM_OUTPUT_TYPE_DIRECTIVE(STREAM, NAME, TYPE)
> +#define ASM_DECLARE_FUNCTION_SIZE(FILE, FNAME, DECL)
> +
> +#define TEXT_SECTION_ASM_OP	"\t.text"
> +#define DATA_SECTION_ASM_OP	"\t.data"
> +#define BSS_SECTION_ASM_OP	"\t.bss"
> +
> +#define CTORS_SECTION_ASM_OP	"\t.section\t.ctors, \"aw\""
> +#define DTORS_SECTION_ASM_OP	"\t.section\t.dtors, \"aw\""
> +
> +#define GLOBAL_ASM_OP "\t.global\t"
> +
> +#undef SUPPORTS_INIT_PRIORITY
> +#define SUPPORTS_INIT_PRIORITY 0
> +
> +#endif

Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[Richard Sandiford]

Evgeny Karpov <Evgeny.Karpov@microsoft.com> writes:
> From 1ea6efa6f88d131884ecef21c4b5d2ecbab14ea7 Mon Sep 17 00:00:00 2001
> From: Zac Walker <zacwalker@microsoft.com>
> Date: Tue, 20 Feb 2024 18:06:36 +0100
> Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for
>  AArch64
>
> Define Cygwin and MinGW environment such as types, SEH definitions,
> shared libraries, etc.
>
> gcc/ChangeLog:
>
> 	* config.gcc: Add Cygwin and MinGW difinitions.
> 	* config/aarch64/aarch64-protos.h
> 	(mingw_pe_maybe_record_exported_symbol): Declare functions
> 	which are used in Cygwin and MinGW environment.
> 	(mingw_pe_section_type_flags): Likewise.
> 	(mingw_pe_unique_section): Likewise.
> 	(mingw_pe_encode_section_info): Likewise.
> 	* config/aarch64/cygming.h: New file.
> ---
>  gcc/config.gcc                      |   1 +
>  gcc/config/aarch64/aarch64-protos.h |   5 +
>  gcc/config/aarch64/cygming.h        | 178 ++++++++++++++++++++++++++++
>  3 files changed, 184 insertions(+)
>  create mode 100644 gcc/config/aarch64/cygming.h
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 498ee702607..96e3508eb30 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -1265,6 +1265,7 @@ aarch64*-*-linux*)
>  	;;
>  aarch64*-*-mingw*)
>  	tm_file="${tm_file} aarch64/aarch64-coff.h"
> +	tm_file="${tm_file} aarch64/cygming.h"
>  	tm_file="${tm_file} mingw/mingw32.h"
>  	tm_file="${tm_file} mingw/mingw-stdint.h"
>  	tmake_file="${tmake_file} aarch64/t-aarch64"
> diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
> index a0b142e0b94..6d85452b0f6 100644
> --- a/gcc/config/aarch64/aarch64-protos.h
> +++ b/gcc/config/aarch64/aarch64-protos.h
> @@ -1109,6 +1109,11 @@ extern void aarch64_output_patchable_area (unsigned int, bool);
>  
>  extern void aarch64_adjust_reg_alloc_order ();
>  
> +extern void mingw_pe_maybe_record_exported_symbol (tree, const char *, int);
> +extern unsigned int mingw_pe_section_type_flags (tree, const char *, int);
> +extern void mingw_pe_unique_section (tree, int);
> +extern void mingw_pe_encode_section_info (tree, rtx, int);
> +
>  bool aarch64_optimize_mode_switching (aarch64_mode_entity);
>  void aarch64_restore_za (rtx);
>  
> diff --git a/gcc/config/aarch64/cygming.h b/gcc/config/aarch64/cygming.h
> new file mode 100644
> index 00000000000..cf47184eb66
> --- /dev/null
> +++ b/gcc/config/aarch64/cygming.h
> @@ -0,0 +1,178 @@
> +/* Operating system specific defines to be used when targeting GCC for
> +   hosting on Windows32, using a Unix style C library and tools.
> +   Copyright (C) 1995-2024 Free Software Foundation, Inc.
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 3, or (at your option)
> +any later version.
> +
> +GCC is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with GCC; see the file COPYING3.  If not see
> +<http://www.gnu.org/licenses/>.  */
> +
> +#ifndef GCC_AARCH64_CYGMING_H
> +#define GCC_AARCH64_CYGMING_H
> +
> +#undef PREFERRED_DEBUGGING_TYPE
> +#define PREFERRED_DEBUGGING_TYPE DINFO_TYPE_NONE
> +
> +#define FASTCALL_PREFIX '@'
> +
> +#define print_reg(rtx, code, file)
> +
> +#define SYMBOL_FLAG_DLLIMPORT 0
> +#define SYMBOL_FLAG_DLLEXPORT 0
> +
> +#define SYMBOL_REF_DLLEXPORT_P(X) \
> +	((SYMBOL_REF_FLAGS (X) & SYMBOL_FLAG_DLLEXPORT) != 0)
> +
> +#undef TARGET_SEH
> +#define TARGET_SEH 0
> +
> +#define SSE_REGNO_P(N) 0
> +#define GENERAL_REGNO_P(N) 0

Could you add a comment to explain how these two macros are consumed?
What is the effect of saying that everything is neither a general
register nor an SSE register?

> +#define SEH_MAX_FRAME_SIZE 0
> +
> +#undef DEFAULT_ABI
> +#define DEFAULT_ABI MS_ABI
> +
> +#undef TARGET_PECOFF
> +#define TARGET_PECOFF 1
> +
> +#include <stdbool.h>
> +#ifdef __MINGW32__
> +#include <stdio.h>
> +#endif
> +
> +extern void mingw_pe_asm_named_section (const char *, unsigned int, tree);
> +extern void mingw_pe_declare_function_type (FILE *file, const char *name,
> +	int pub);
> +
> +#define TARGET_ASM_NAMED_SECTION  mingw_pe_asm_named_section
> +
> +/* Select attributes for named sections.  */
> +#define TARGET_SECTION_TYPE_FLAGS  mingw_pe_section_type_flags
> +
> +#define TARGET_ASM_UNIQUE_SECTION mingw_pe_unique_section
> +#define TARGET_ENCODE_SECTION_INFO  mingw_pe_encode_section_info
> +
> +/* Declare the type properly for any external libcall.  */
> +#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN) \
> +  mingw_pe_declare_function_type (FILE, XSTR (FUN, 0), 1)
> +
> +#define TARGET_OS_CPP_BUILTINS()					\
> +  do									\
> +    {									\
> +      builtin_define ("__MSVCRT__");					\
> +      builtin_define ("__MINGW32__");					\
> +      builtin_define ("_WIN32");					\
> +      builtin_define_std ("WIN32");					\
> +      builtin_define_std ("WINNT");					\
> +      builtin_define_with_int_value ("_INTEGRAL_MAX_BITS",		\
> +				TYPE_PRECISION (intmax_type_node));	\
> +      builtin_define ("__MINGW64__");					\
> +      builtin_define_std ("WIN64");					\
> +      builtin_define ("_WIN64");					\
> +      builtin_define ("__stdcall=__attribute__((__stdcall__))");	\
> +      builtin_define ("__fastcall=__attribute__((__fastcall__))");	\
> +      builtin_define ("__thiscall=__attribute__((__thiscall__))");	\
> +      builtin_define ("__cdecl=__attribute__((__cdecl__))");		\
> +    }									\
> +  while (0)
> +
> +/* Windows64 continues to use a 32-bit long type.  */
> +#undef LONG_TYPE_SIZE
> +#define LONG_TYPE_SIZE 32

Just curious: this is AFAIK the first IL32P64 ABI for AArch64.
Do things Just Work, including for things like arm_neon.h and
other ACLE header files?  I'm pleasantly surprised if so :)

> +
> +#undef DEFAULT_SIGNED_CHAR
> +#define DEFAULT_SIGNED_CHAR 1
> +
> +#undef SIZE_TYPE
> +#undef PTRDIFF_TYPE
> +#define SIZE_TYPE "long long unsigned int"
> +#define PTRDIFF_TYPE "long long int"
> +
> +#undef WCHAR_TYPE_SIZE
> +#undef WCHAR_TYPE
> +#define WCHAR_TYPE_SIZE 16
> +#define WCHAR_TYPE "short unsigned int"
> +
> +#define drectve_section() \
> +  (fprintf (asm_out_file, "\t.section\t.drectve\n"), \
> +   in_section = NULL)
> +
> +
> +/* Enable alias attribute support.  */
> +#ifndef SET_ASM_OP
> +#define SET_ASM_OP "\t.set\t"
> +#endif
> +
> +/* GNU as supports weak symbols on PECOFF.  */
> +#ifdef HAVE_GAS_WEAK
> +#define ASM_WEAKEN_LABEL(FILE, NAME)	\
> +  do					\
> +    {					\
> +      fputs ("\t.weak\t", (FILE));	\
> +      assemble_name ((FILE), (NAME));	\
> +      fputc ('\n', (FILE));		\
> +    }					\
> +  while (0)
> +
> +#endif /* HAVE_GAS_WEAK.  */
> +
> +/* Get tree.cc to declare a target-specific specialization of
> +   merge_decl_attributes.  */
> +#define TARGET_DLLIMPORT_DECL_ATTRIBUTES 1
> +
> +#define ASM_OUTPUT_ADDR_DIFF_ELT(STREAM, BODY, VALUE, REL)		\
> +  do {									\
> +    switch (GET_MODE (BODY))						\
> +      {									\
> +      case E_QImode:							\
> +	asm_fprintf (STREAM, "\t.byte\t(%LL%d - %LLrtx%d) / 4\n",	\
> +		     VALUE, REL);					\
> +	break;								\
> +      case E_HImode:							\
> +	asm_fprintf (STREAM, "\t.2byte\t(%LL%d - %LLrtx%d) / 4\n",	\
> +		     VALUE, REL);					\
> +	break;								\
> +      case E_SImode:							\
> +      case E_DImode: /* See comment in aarch64_output_casesi.  */	\
> +	asm_fprintf (STREAM, "\t.word\t(%LL%d - %LLrtx%d) / 4\n",	\
> +		     VALUE, REL);					\
> +	break;								\
> +      default:								\
> +	gcc_unreachable ();						\
> +      }									\
> +  } while (0)
> +
> +#define READONLY_DATA_SECTION_ASM_OP "\t.section\t.rdata,\"dr\""
> +
> +#undef  SUBTARGET_OVERRIDE_OPTIONS
> +#define SUBTARGET_OVERRIDE_OPTIONS			\
> +  do {							\
> +    flag_stack_check = STATIC_BUILTIN_STACK_CHECK;	\

I suppose this is more of a generic mingw/cygwin question, but does
this mean that stack checking cannot be explicitly disabled by a
user who "knows what they are doing"?

Thanks,
Richard

> +  } while (0)
> +
> +
> +#define SUPPORTS_ONE_ONLY 1
> +
> +/* Define this to be nonzero if static stack checking is supported.  */
> +#define STACK_CHECK_STATIC_BUILTIN 1
> +
> +#ifndef HAVE_GAS_ALIGNED_COMM
> +# define HAVE_GAS_ALIGNED_COMM 0
> +#endif
> +
> +#undef MAX_OFILE_ALIGNMENT
> +#define MAX_OFILE_ALIGNMENT (8192 * 8)
> +
> +#endif

Re: [PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements

[Richard Sandiford]

Evgeny Karpov <Evgeny.Karpov@microsoft.com> writes:
> The calling ABI enum definition has been done following a similar convention in 
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-opts.h;h=ef2825803b32001b9632769bdff196d1e43d27ba;hb=refs/heads/master#l41
>
> MS_ABI is used in gcc/config/i386/mingw32.h and gcc/config/i386/winnt-d.cc
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/mingw32.h;h=58304fc55f629648e47490fd3c0f3db3858e4fd8;hb=refs/heads/master#l22
>
> These files are moved to the mingw folder in the patch series.
> https://gcc.gnu.org/pipermail/gcc-patches/attachments/20240221/5e75c464/attachment.txt
>
> 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

>
> Regards,
> Evgeny
>
>
> Thursday, February 22, 2024 12:40 PM
> Richard Earnshaw (lists) wrote:
>
>>
> +/* Available call ABIs.  */
> +enum calling_abi
> +{
> +  AARCH64_EABI = 0,
> +  MS_ABI = 1
> +};
> +
>
> The convention in this file seems to be that all enum types to start with aarch64.  Also, the enumeration values should start with the name of the enumeration type in upper case, so:
>
> enum aarch64_calling_abi
> {
>   AARCH64_CALLING_ABI_EABI,
>   AARCH64_CALLING_ABI_MS
> };
>
> or something very much like that.
>
> R.

Re: [PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements

[Andrew Pinski]

On Fri, Feb 23, 2024 at 9:51 AM Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Evgeny Karpov <Evgeny.Karpov@microsoft.com> writes:
> > The calling ABI enum definition has been done following a similar convention in
> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-opts.h;h=ef2825803b32001b9632769bdff196d1e43d27ba;hb=refs/heads/master#l41
> >
> > MS_ABI is used in gcc/config/i386/mingw32.h and gcc/config/i386/winnt-d.cc
> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/mingw32.h;h=58304fc55f629648e47490fd3c0f3db3858e4fd8;hb=refs/heads/master#l22
> >
> > These files are moved to the mingw folder in the patch series.
> > https://gcc.gnu.org/pipermail/gcc-patches/attachments/20240221/5e75c464/attachment.txt
> >
> > 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?

There is arm64ec ABI defined for aarch64 windows which is a different
ABI from the standard windows aarch64 ABI, though I am not sure if it
supported with the patches here.
It is documented at
https://learn.microsoft.com/en-us/cpp/build/arm64ec-windows-abi-conventions?view=msvc-170
.

Thanks,
Andrew

>
> 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
>
> >
> > Regards,
> > Evgeny
> >
> >
> > Thursday, February 22, 2024 12:40 PM
> > Richard Earnshaw (lists) wrote:
> >
> >>
> > +/* Available call ABIs.  */
> > +enum calling_abi
> > +{
> > +  AARCH64_EABI = 0,
> > +  MS_ABI = 1
> > +};
> > +
> >
> > The convention in this file seems to be that all enum types to start with aarch64.  Also, the enumeration values should start with the name of the enumeration type in upper case, so:
> >
> > enum aarch64_calling_abi
> > {
> >   AARCH64_CALLING_ABI_EABI,
> >   AARCH64_CALLING_ABI_MS
> > };
> >
> > or something very much like that.
> >
> > R.

Re: [PATCH v1 00/13] Add aarch64-w64-mingw32 target

[Richard Sandiford]

"Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com> writes:
> On 21/02/2024 17:47, Evgeny Karpov wrote:
>> Hello,
>> 
>> We would like to take your attention to the review of changes for the
>> new GCC target, aarch64-w64-mingw32. The new target will be
>> supported, tested, added to CI, and maintained by Linaro. This marks
>> the first of three planned patch series contributing to the GCC C
>> compiler's support for Windows Arm64.
>> 
>> 1. Minimal aarch64-w64-mingw32 C implementation to cross-compile
>> hello-world with libgcc for Windows Arm64 using MinGW.
>> 2. Extension of the aarch64-w64-mingw32 C implementation to
>> cross-compile OpenSSL, OpenBLAS, FFmpeg, and libjpeg-turbo. All
>> packages successfully pass tests.
>> 3. Addition of call stack support for debugging, resolution of
>> optimization issues in the C compiler, and DLL export/import for the
>> aarch64-w64-mingw32 target.
>> 
>> This patch series introduces the 1st point, which involves building
>> hello-world for the aarch64-w64-mingw32 target. The patch depends on
>> the binutils changes for the aarch64-w64-mingw32 target that have
>> already been merged.
>> 
>> The binutils should include recent relocation fixes.
>> f87eaf8ff3995a5888c6dc4996a20c770e6bcd36
>> aarch64: Add new relocations and limit COFF AArch64 relocation offsets
>> 
>> The series is structured in a way to trivially show that it should not
>> affect any other targets.
>> 
>> In this patch, several changes have been made to support the
>> aarch64-w64-mingw32 target for GCC. The modifications include the
>> definition of the MS ABI for aarch64, adjustments to FIXED_REGISTERS
>> and STATIC_CHAIN_REGNUM for different ABIs, and specific definitions
>> for COFF format on AArch64. Additionally, the patch reuses MinGW
>> <stdint.h> types and definitions from i386, relocating them to a new
>> mingw folder for shared usage between both targets.
>> 
>> MinGW-specific options have been introduced for AArch64, along with
>> override options for aarch64-w64-mingw32. Builtin stack probing for
>> override options for aarch64-w64-mingw32. Builtin stack probing for
>> AArch64 has been enabled as an alternative for chkstk. Symbol name
>> encoding and section information handling for aarch64-w64-mingw32 have
>> been incorporated, and the MinGW environment has been added, which
>> will also be utilized for defining the Cygwin environment in the
>> future.
>> 
>> The patch includes renaming "x86 Windows Options" to "Cygwin and MinGW
>> Options," which now encompasses AArch64 as well. AArch64-specific
>> Cygwin and MinGW Options have been introduced for the unique
>> requirements of the AArch64 architecture.
>> 
>> Function type declaration and named sections support have been added.
>> The necessary objects for Cygwin and MinGW have been built for the
>> aarch64-w64-mingw32 target, and relevant files such as msformat-c.cc
>> and winnt-d.cc have been moved to the mingw folder for reuse in
>> AArch64.
>> 
>> Furthermore, the aarch64-w64-mingw32 target has been included in both
>> libatomic and libgcc, ensuring support for the AArch64 architecture
>> within these libraries. These changes collectively enhance the
>> capabilities of GCC for the specified target.
>> 
>> Coauthors: Zac Walker <zacwalker@microsoft.com>,
>> Mark Harmstone <mark@harmstone.com>  and
>> Ron Riddle <ron.riddle@microsoft.com>
>> 
>> Refactored, prepared, and validated by 
>> Radek Barton <radek.barton@microsoft.com> and 
>> Evgeny Karpov <evgeny.karpov@microsoft.com>
>> 
>> Special thanks to the Linaro GNU toolchain team for internal review
>> and assistance in preparing the patch series!
>> 
>> Regards,
>> Evgeny
>
> Thanks for posting this.

Seconded. :)  Thanks also for the very clear organisation of the series,
and for commonising code rather than cut-&-pasting it.

FWIW, I agree with all the comments posted so far, and just sent
some other comments too.  I think my main high-level comments are:

- Could you double-check that all the code in the common files are
  used on both aarch64 and x86?  I think it's OK to move code outside
  of x86 even if aarch64 doesn't want to use it, provided that it makes
  conceptual target-independent sense.  But it's not clear whether
  unused code is deliberate or not (e.g. the EXTRA_OS_CPP_BUILTINS
  thing I mentioned in the part 2 review).

- Could you test with all languages enabled, and say what languages
  are supported?  Some languages require an existing compiler for
  the same language and so are more difficult to bootstrap for
  a new port.  I suppose you'd need a cross-host build first,
  then use the cross-compiled compilers to bootstrap.

Thanks,
Richard

Re: [PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements

[Martin Storsjö]

On Fri, 23 Feb 2024, Richard Sandiford wrote:

> Are there two distinct ABIs for aarch64-*-mingw*?  Or are these 
> distinctions ignored on aarch64 and just retained for compatibility?

On Windows on AArch64, the calling convention normally matches regular 
AAPCS64 - so the ms_abi attribute normally has no effect. However, for 
variadic functions, the calling convention differs, so the ms_abi 
attribute could be used to implement functions with the Windows vararg 
calling convention on Linux.

(As far as I know, the correct Windows vararg calling convention is not 
yet implemented in this patch series, but would be a later addition.)

Clang/LLVM does implement the Windows AArch64 vararg calling convention, 
and it used to be necessary for Wine on AArch64 before, but as Jacek 
mentioned, it's no longer needed by Wine.

ARM64EC is an entirely different thing though, both out of scope for this 
patchset, and also a much bigger thing than an MS_ABI attribute.

// Martin

Re: [PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[Bernhard Reutner-Fischer]

On Thu, 22 Feb 2024 15:56:46 +0000
Evgeny Karpov <Evgeny.Karpov@microsoft.com> wrote:

> A ChangeLog template using "Moved... ...here" has been generated by contrib/mklog.py.
> It seems that it needs modification.
> 
> Regards,
> Evgeny
> 
> -----Original Message-----
> Thursday, February 22, 2024 12:11 PM
> Richard Earnshaw (lists) wrote:
> 
> > The ChangeLog has to be expressed in present tense, as mandated by the standard; s/Moved/Move/g etc.  
> 
> Agreed, but that's a detail that we can get to once the patch has been properly reviewed.
> 

Excellent, two patches for the price of one :)

diff --git a/contrib/mklog.py b/contrib/mklog.py
index d764fb41f99..7d8d554b15e 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -277,7 +277,7 @@ def generate_changelog(data, no_functions=False, fill_pr_titles=False,
                 # it used to be path.source_file[2:]
                 relative_path = get_rel_path_if_prefixed(file.source_file[2:],
                                                          changelog)
-                out = append_changelog_line(out, relative_path, 'Moved to...')
+                out = append_changelog_line(out, relative_path, 'Move to...')
                 new_path = get_rel_path_if_prefixed(file.target_file[2:],
                                                     changelog)
                 out += f'\t* {new_path}: ...here.\n'


cheers

[PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements

[Evgeny Karpov]

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

[PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements

[Evgeny Karpov]

Hi Martin,

Thank you for the clarification regarding the vararg implementation.
It is correct. The work is still in progress and will be included in
a later patch series.

ARM64EC is a separate work, which is outside the scope of the current
contribution plan.

Regards,
Evgeny

-----Original Message-----
Friday, February 23, 2024 9:37 PM
Martin Storsjö wrote: 

On Fri, 23 Feb 2024, Richard Sandiford wrote:

> Are there two distinct ABIs for aarch64-*-mingw*?  Or are these 
> distinctions ignored on aarch64 and just retained for compatibility?

(As far as I know, the correct Windows vararg calling convention is not yet implemented in this patch series, but would be a later addition.)

ARM64EC is an entirely different thing though, both out of scope for this patchset, and also a much bigger thing than an MS_ABI attribute.

// Martin

Re: [PATCH v1 01/13] Introduce aarch64-w64-mingw32 target

[Fangrui Song]

+Martin who may have an opinion
(https://github.com/mstorsjo/llvm-mingw supports aarch64)

On Fri, Feb 23, 2024 at 6:15 AM Evgeny Karpov
<Evgeny.Karpov@microsoft.com> wrote:
>
> Hi Andrew and Richard,
>
> Thank you for pointing out there's no need for a 64-bit ISA and the big-endian target.
> These changes will be addressed in v2.
>
> Regards,
> Evgeny
>
> -----Original Message-----
> Thursday, February 22, 2024 12:33 PM
> Richard Earnshaw (lists)  wrote:
> >
> +aarch64*-*-mingw*)
>
> Other targets are a bit inconsistent here as well, but, as Andrew mentioned, if you don't want to handle big-endian, it might be better to match aarch64-*-mingw* here.
>
>
> -----Original Message-----
> Wednesday, February 21, 2024 7:23 PM
> Andrew Pinski wrote:
>
> > need_64bit_isa=yes
>
> This is not needed in the patch as it is only used for x86_64 targets.
>
> Should you make sure nobody specifies the big-endian target:
> aarch64_be-w64-mingw32  ?
>


-- 
宋方睿

[PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[Evgeny Karpov]

Thank you for the historical information regarding the introduction 
of the features. I can confirm that removing the HAVE_GAS_WEAK check
and setting HAVE_GAS_ALIGNED_COMM to 1 by default works well.
These changes will be included in v2.

Regards,
Evgeny


-----Original Message-----
Thursday, February 22, 2024 2:23 PM
Richard Earnshaw (lists) wrote:

>
+/* GNU as supports weak symbols on PECOFF.  */ #ifdef HAVE_GAS_WEAK

Can't we assume this is true?  It was most likely needed on i386 because support goes back longer than the assembler had this feature, but it looks like it was added in 2000, or thereabouts, so significantly before aarch64 was supported in the assembler.

+#ifndef HAVE_GAS_ALIGNED_COMM

And this was added to GCC in 2009, which probably means it predates aarch64-coff support in gas as well.

R.

[PATCH v1 13/13] Add aarch64-w64-mingw32 target to libgcc

[Evgeny Karpov]

The target will be adjusted to aarch64-*-mingw* in config.gcc. This
change will ensure consistency with the target in libgcc.

Regards,
Evgeny


-----Original Message-----
Thursday, February 22, 2024 2:36 PM
Richard Earnshaw (lists) wrote:

>
+aarch64-*-mingw*)

This doesn't match the glob pattern you added to config.gcc in an earlier patch, but see my comment on that.  The two should really be consistent with each other or you might get build failures late on.

R.

Re: [PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[Mark Harmstone]

On 22/2/24 11:11, Richard Earnshaw (lists) wrote:
>> Most of the free world has left COFF behind since several decades, so I won't comment on that. YMMV.
> This isn't helpful.  Windows platforms use (a derivative of) COFF, so that's what the tools need to use when targetting that platform.

Also, there are relocation types needed for Windows programs that are supported in COFF but not in ELF object files.

Mark

Re: [PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements

[Mark Harmstone]

On 23/2/24 17:54, Andrew Pinski wrote:
> There is arm64ec ABI defined for aarch64 windows which is a different
> ABI from the standard windows aarch64 ABI, though I am not sure if it
> supported with the patches here.
> It is documented at
> https://learn.microsoft.com/en-us/cpp/build/arm64ec-windows-abi-conventions?view=msvc-170
> .

ARM64EC would also need a lot of work in binutils, and AFAIK no-one's been working on that yet.

Mark

Re: [PATCH v1 00/13] Add aarch64-w64-mingw32 target

[NightStrike]

On Wed, Feb 21, 2024 at 12:48 PM Evgeny Karpov
<Evgeny.Karpov@microsoft.com> wrote:
>
> Hello,
>
> We would like to take your attention to the review of changes for the
> new GCC target, aarch64-w64-mingw32. The new target will be
> supported, tested, added to CI, and maintained by Linaro. This marks
> the first of three planned patch series contributing to the GCC C
> compiler's support for Windows Arm64.
>
> 1. Minimal aarch64-w64-mingw32 C implementation to cross-compile
> hello-world with libgcc for Windows Arm64 using MinGW.
> 2. Extension of the aarch64-w64-mingw32 C implementation to
> cross-compile OpenSSL, OpenBLAS, FFmpeg, and libjpeg-turbo. All
> packages successfully pass tests.
> 3. Addition of call stack support for debugging, resolution of
> optimization issues in the C compiler, and DLL export/import for the
> aarch64-w64-mingw32 target.
>
> This patch series introduces the 1st point, which involves building
> hello-world for the aarch64-w64-mingw32 target. The patch depends on
> the binutils changes for the aarch64-w64-mingw32 target that have
> already been merged.
>
> The binutils should include recent relocation fixes.
> f87eaf8ff3995a5888c6dc4996a20c770e6bcd36
> aarch64: Add new relocations and limit COFF AArch64 relocation offsets
>
> The series is structured in a way to trivially show that it should not
> affect any other targets.

To be clear, because of the refactoring, it will affect x86/x64
Windows targets.  Can you do a testsuite run before and after and see
that it doesn't get worse?  The full testsuite for all languages for
Windows isn't in great shape, but it's not awful.  Some languages,
like Rust and Fortran, have ~10 FAILs.  C and C++ have several
thousand.

In particular, there are quite a few testsuite test FAILs regarding MS
ABI that hopefully do not get worse.

Lastly, I don't think I see in the current patch series where you add
new testsuite coverage for aarch64-specific bits.  I probably missed
it, so feel free to helpfully correct me there :)  I'd be curious to
see how the tests were written to take into account target differences
(using for example the dejagnu feature procs) and other nuances.

Re: [PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[Bernhard Reutner-Fischer]

On Sun, 25 Feb 2024 at 22:12, Mark Harmstone <mark@harmstone.com> wrote:
> Also, there are relocation types needed for Windows programs that are supported in COFF but not in ELF object files.
>

Right, it's been a long time since i last dealt with PECOFF and i had
assumed that things might have changed in the meantime.

PS: Please don't forget to add an entry to contrib/config-list.mk
thanks

[PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

[Evgeny Karpov]

This change has been refactored based on the review and will be included in v2.

Original aarch64.h will remain unchanged, and the required definition for MS ABI will be implemented in aarch64-abi-ms.h. The reference to this file will be added to config.gcc.
This change has been verified, and it appears to work correctly.

The X18 register should not be used in any case.
The call used flag should be set to 0 for the X18 register to prevent its use in function calls.
The same applies to the static chain. The X17 register will be used instead of X18.

Regards,
Evgeny


gcc/config.gcc
@@ -1263,7 +1263,8 @@

aarch64-*-mingw*)
+       tm_file="${tm_file} aarch64/aarch64-abi-ms.h"



gcc/config/aarch64/aarch64-abi-ms.h
/* Copyright */

/* X18 reserved for the TEB on Windows.  */

#undef FIXED_REGISTERS
#define FIXED_REGISTERS	                            \
  {					                                \
    0, 0, 0, 0,   0, 0, 0, 0,	/* R0 - R7 */		\
    0, 0, 0, 0,   0, 0, 0, 0,	/* R8 - R15 */		\
    0, 0, 1, 0,   0, 0, 0, 0,	/* R16 - R23.  */	\
    0, 0, 0, 0,   0, 1, 0, 1,	/* R24 - R30, SP */	\
    0, 0, 0, 0,   0, 0, 0, 0,   /* V0 - V7 */       \
    0, 0, 0, 0,   0, 0, 0, 0,   /* V8 - V15 */		\
    0, 0, 0, 0,   0, 0, 0, 0,   /* V16 - V23 */     \
    0, 0, 0, 0,   0, 0, 0, 0,   /* V24 - V31 */     \
    1, 1, 1, 1,			/* SFP, AP, CC, VG */       \
    0, 0, 0, 0,   0, 0, 0, 0,   /* P0 - P7 */       \
    0, 0, 0, 0,   0, 0, 0, 0,   /* P8 - P15 */      \
    1, 1,			/* FFR and FFRT */	            \
    1, 1, 1, 1, 1, 1, 1, 1	/* Fake registers */	\
  }

#undef CALL_REALLY_USED_REGISTERS
#define CALL_REALLY_USED_REGISTERS                  \
  {						                            \
    1, 1, 1, 1,   1, 1, 1, 1,	/* R0 - R7 */		\
    1, 1, 1, 1,   1, 1, 1, 1,	/* R8 - R15 */		\
    1, 1, 0, 0,   0, 0, 0, 0,   /* R16 - R23.  */   \
    0, 0, 0, 0,   0, 1, 1, 1,	/* R24 - R30, SP */	\
    1, 1, 1, 1,   1, 1, 1, 1,	/* V0 - V7 */		\
    0, 0, 0, 0,   0, 0, 0, 0,	/* V8 - V15 */		\
    1, 1, 1, 1,   1, 1, 1, 1,   /* V16 - V23 */     \
    1, 1, 1, 1,   1, 1, 1, 1,   /* V24 - V31 */     \
    1, 1, 1, 0,			/* SFP, AP, CC, VG */       \
    1, 1, 1, 1,   1, 1, 1, 1,	/* P0 - P7 */       \
    1, 1, 1, 1,   1, 1, 1, 1,	/* P8 - P15 */      \
    1, 1,			/* FFR and FFRT */              \
    0, 0, 0, 0, 0, 0, 0, 0	/* Fake registers */	\
  }

#undef  STATIC_CHAIN_REGNUM
#define STATIC_CHAIN_REGNUM		R17_REGNUM

 

-----Original Message-----
Thursday, February 22, 2024 12:55 PM 
Richard Earnshaw (lists) wrote:

+/* X18 reserved for the TEB on Windows.  */ #ifdef TARGET_ARM64_MS_ABI 
+# define FIXED_X18 1 # define CALL_USED_X18 0 #else # define FIXED_X18 
+0 # define CALL_USED_X18 1 #endif

I'm not overly keen on ifdefs like this (and the one below), it can get quite confusing if we have to support more than a couple of ABIs.  Perhaps we could create a couple of new headers, one for the EABI (which all existing targets would then need to include) and one for the MS ABI.  Then the mingw port would use that instead of the EABI header.

An alternative is to make all this dynamic, based on the setting of the aarch64_calling_abi enum and to make the adjustments in aarch64_conditional_register_usage.

+# define CALL_USED_X18 0

Is that really correct?  If the register is really reserved, but some code modifies it anyway, this will cause the compiler to restore the old value at the end of a function; generally, for a reserved register, code that knows what it's doing would want to make permanent changes to this value.

+#ifdef TARGET_ARM64_MS_ABI
+# define STATIC_CHAIN_REGNUM           R17_REGNUM
+#else
+# define STATIC_CHAIN_REGNUM           R18_REGNUM
+#endif

If we went the enum way, we'd want something like

#define STATIC_CHAIN_REGNUM (calling_abi == AARCH64_CALLING_ABI_MS ? R17_REGNUM : R18_REGNUM)

R.

[PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

[Evgeny Karpov]

Thank you Jacek for clarifying Wine's needs for ms_abi!
Work on vararg support is planned.

Regards,
Evgeny

-----Original Message-----
Friday, February 23, 2024 5:10 PM 
Jacek Caban wrote:

> Dynamically might be needed also if we want to support ms_abi 
> attribute and/or -mabi=ms to support the wine folks.

Wine no longer needs ms_abi, it was needed for PE-in-ELF modules in the past. We use use proper PE files now, so we need a cross compiler, but no special attributes. aarch64-w64-mingw32 is already well supported by Wine when using llvm-mingw, so as soon as GCC properly supports the ABI, Wine should just work with it, in theory. I didn't try it, but I don't see things like vararg support in this patchset nor in the repo, so I assume it won't work yet.


Thanks for the work!

Jacek

[PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

[Evgeny Karpov]

In user mode on Windows, it points to TEB (Thread Environment Block).
more information here
https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers
https://learn.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-teb

Regards,
Evgeny

-----Original Message-----
Friday, February 23, 2024 5:56 PM
Richard Sandiford wrote:

How does the MS ABI use this register?  Same question for Darwin I suppose.

Thanks,
Richard

[PATCH v1 04/13] aarch64: Add aarch64-w64-mingw32 COFF

[Evgeny Karpov]

Thanks for noticing this definition.
Yes, it was added to enable proper types in mingw/mingw-stdint.h for AArch64.
Based on the review, TARGET_64BIT has been excluded from aarch64/aarch64-coff.h, and 
mingw/mingw-stdint.h has been modified to support AArch64.

Regards,
Evgeny


gcc/config/mingw/mingw-stdint.h
@@ -46,5 +46,10 @@

-#define INTPTR_TYPE (TARGET_64BIT ? "long long int" : "int")
-#define UINTPTR_TYPE (TARGET_64BIT ? "long long unsigned int" : "unsigned int")
+#if defined (TARGET_AARCH64_MS_ABI)
+# define INTPTR_TYPE "long long int"
+# define UINTPTR_TYPE "long long unsigned int"
+#else
+# define INTPTR_TYPE (TARGET_64BIT ? "long long int" : "int")
+# define UINTPTR_TYPE (TARGET_64BIT ? "long long unsigned int" : "unsigned int")
+#endif


-----Original Message-----
Friday, February 23, 2024 6:02 PM 
Richard Sandiford wrote:


The only surprising thing here to me was:

> +
> +#define TARGET_64BIT 1

...this.  Does some code that is shared between x86 and aarch64 rely on this definition?  It might be worth identifying the code in a comment if so.

Thanks,
Richard

[PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[Evgeny Karpov]

Thank you for the fix, Bernhard! Please send it as a separate patch.

Regards,
Evgeny

-----Original Message-----
Sent: Monday, February 26, 2024 9:18 AM
Bernhard Reutner-Fischer 

PS: Please don't forget to add an entry to contrib/config-list.mk thanks

[PATCH v1 10/13] Rename "x86 Windows Options" to "Cygwin and MinGW Options"

[Evgeny Karpov]

@xref{Cygwin and MinGW Options} re-direct from "x86 Windows Options" will be added in v2. Thanks!

Regards,
Evgeny


-----Original Message-----
Thursday, February 22, 2024 2:32 PM 
Richard Earnshaw (lists) wrote:

For this change you might want to put some form of re-direct in the manual under the old name so that anybody used to looking for the old entry will know where things have been moved to.  Something like

x86 Windows Options
  See xref(Cygwin and MinGW Options).

R.

[PATCH v1 00/13] Add aarch64-w64-mingw32 target

[Evgeny Karpov]

Richard, thank you for the initial review! Hopefully, the required actions have been addressed, which should improve the patch quality in v2.

Regards,
Evgeny

-----Original Message-----
Thursday, February 22, 2024 2:40 PM 
Richard Earnshaw (lists) wrote:

Thanks for posting this.

I've only read quickly through this patch series and responded where I think some action is obviously required.  That doesn't necessarily mean the other patches are perfect, though, just that nothing immediately caught my attention.

R.

[PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[Evgeny Karpov]

SEH is not implemented yet and needs to be disabled in mingw/winnt.cc. Disabling every SEH function that uses references to these macros might trigger significant refactoring, and to avoid this, required macros are defined with 0. It is needed only for compilation. A comment with an explanation will be added.

It looks like IL32P64 works. It has been tested on OpenSSL, OpenBLAS, libjpeg-turbo, and FFmpeg packages. No issues have been detected with it.

Correct, stack checking cannot be explicitly disabled by the user. It will be interesting to know cases when it is needed. GCC uses stack probing only when the stack size is exceeded; size optimization is not an option then.

Regards,
Evgeny


-----Original Message-----
Friday, February 23, 2024 6:16 PM 
Richard Sandiford wrote:
 
> +
> +#undef TARGET_SEH
> +#define TARGET_SEH 0
> +
> +#define SSE_REGNO_P(N) 0
> +#define GENERAL_REGNO_P(N) 0

Could you add a comment to explain how these two macros are consumed?
What is the effect of saying that everything is neither a general register nor an SSE register?

> +#define SEH_MAX_FRAME_SIZE 0


> +/* Windows64 continues to use a 32-bit long type.  */ #undef 
> +LONG_TYPE_SIZE #define LONG_TYPE_SIZE 32

Just curious: this is AFAIK the first IL32P64 ABI for AArch64.
Do things Just Work, including for things like arm_neon.h and other ACLE header files?  I'm pleasantly surprised if so :)

I suppose this is more of a generic mingw/cygwin question, but does this mean that stack checking cannot be explicitly disabled by a user who "knows what they are doing"?

Thanks,
Richard

Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[Andrew Pinski]

On Tue, Feb 27, 2024 at 1:18 PM Evgeny Karpov
<Evgeny.Karpov@microsoft.com> wrote:
>
> SEH is not implemented yet and needs to be disabled in mingw/winnt.cc. Disabling every SEH function that uses references to these macros might trigger significant refactoring, and to avoid this, required macros are defined with 0. It is needed only for compilation. A comment with an explanation will be added.

What does this mean with respect to C++ exceptions? Or you using SJLJ
exceptions support or the dwarf unwinding ones without SEH support?
I am not sure if SJLJ exceptions is well tested any more in GCC either.

Also I have a question if you ran the full GCC/G++ testsuites and what
were the results?
If you did run it, did you use a cross compiler or the native
compiler? Did you do a bootstrap (GCC uses C++ but no exceptions
though)?
If you run using a cross compiler, did you use ssh or some other route
to run the applications?

Thanks,
Andrew Pinski

>
> It looks like IL32P64 works. It has been tested on OpenSSL, OpenBLAS, libjpeg-turbo, and FFmpeg packages. No issues have been detected with it.
>
> Correct, stack checking cannot be explicitly disabled by the user. It will be interesting to know cases when it is needed. GCC uses stack probing only when the stack size is exceeded; size optimization is not an option then.
>
> Regards,
> Evgeny
>
>
> -----Original Message-----
> Friday, February 23, 2024 6:16 PM
> Richard Sandiford wrote:
>
> > +
> > +#undef TARGET_SEH
> > +#define TARGET_SEH 0
> > +
> > +#define SSE_REGNO_P(N) 0
> > +#define GENERAL_REGNO_P(N) 0
>
> Could you add a comment to explain how these two macros are consumed?
> What is the effect of saying that everything is neither a general register nor an SSE register?
>
> > +#define SEH_MAX_FRAME_SIZE 0
>
>
> > +/* Windows64 continues to use a 32-bit long type.  */ #undef
> > +LONG_TYPE_SIZE #define LONG_TYPE_SIZE 32
>
> Just curious: this is AFAIK the first IL32P64 ABI for AArch64.
> Do things Just Work, including for things like arm_neon.h and other ACLE header files?  I'm pleasantly surprised if so :)
>
> I suppose this is more of a generic mingw/cygwin question, but does this mean that stack checking cannot be explicitly disabled by a user who "knows what they are doing"?
>
> Thanks,
> Richard
>

Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[NightStrike]

> -----Original Message-----
> Friday, February 23, 2024 6:16 PM
> Richard Sandiford wrote:
>
> > +
> > +#undef TARGET_SEH
> > +#define TARGET_SEH 0
> > +
> > +#define SSE_REGNO_P(N) 0
> > +#define GENERAL_REGNO_P(N) 0
>
> Could you add a comment to explain how these two macros are consumed?
> What is the effect of saying that everything is neither a general register nor an SSE register?
>
> > +#define SEH_MAX_FRAME_SIZE 0

On Tue, Feb 27, 2024 at 4:17 PM Evgeny Karpov
<Evgeny.Karpov@microsoft.com> wrote:
>
> SEH is not implemented yet and needs to be disabled in mingw/winnt.cc. Disabling every SEH function that uses references to these macros might trigger significant refactoring, and to avoid this, required macros are defined with 0. It is needed only for compilation. A comment with an explanation will be added.

This is all the more reason why you need to show the full testsuite
run for x86/x64 mingw as per my previous message.  We do use SEH by
default on x64.

Also, this is a friendly reminder that the GCC list is a bottom
posting list, not top posting, which is the default for your email
client.  I fixed this email for you.

[PATCH v1 00/13] Add aarch64-w64-mingw32 target

[Evgeny Karpov]

Friday, February 23, 2024 7:00 PM
Richard Sandiford wrote:

> Seconded. :)  Thanks also for the very clear organisation of the series, and for
> commonising code rather than cut-&-pasting it.

Thank you, Richard, for the valuable feedback. It is great to hear
that the series structure is easy to review. That work has been
done before submitting v1.
 
> FWIW, I agree with all the comments posted so far, and just sent some other
> comments too.  I think my main high-level comments are:
> 
> - Could you double-check that all the code in the common files are
>   used on both aarch64 and x86?  I think it's OK to move code outside
>   of x86 even if aarch64 doesn't want to use it, provided that it makes
>   conceptual target-independent sense.  But it's not clear whether
>   unused code is deliberate or not (e.g. the EXTRA_OS_CPP_BUILTINS
>   thing I mentioned in the part 2 review).

All files from the mingw folder are used by the aarch64 target.
Some of them are used partially as mingw.cc. As mentioned in the
cover letter, the current contribution covers only the C scope.
EXTRA_OS_CPP_BUILTINS is one example which is not used.
 
> - Could you test with all languages enabled, and say what languages
>   are supported?  Some languages require an existing compiler for
>   the same language and so are more difficult to bootstrap for
>   a new port.  I suppose you'd need a cross-host build first,
>   then use the cross-compiled compilers to bootstrap.
> 
> Thanks,
> Richard

Our CI for the current contribution uses and tests only the C
language for the aarch64-w64-mingw32 target.

Regards,
Evgeny

[PATCH v1 00/13] Add aarch64-w64-mingw32 target

[Evgeny Karpov]

Monday, February 26, 2024 2:30 AM 
NightStrike wrote:

> To be clear, because of the refactoring, it will affect x86/x64 Windows targets.
> Can you do a testsuite run before and after and see that it doesn't get worse?
> The full testsuite for all languages for Windows isn't in great shape, but it's not
> awful.  Some languages, like Rust and Fortran, have ~10 FAILs.  C and C++ have
> several thousand.
> 
> In particular, there are quite a few testsuite test FAILs regarding MS ABI that
> hopefully do not get worse.
> 

Thank you for bringing it up! Our CI will be extended to test the x64
mingw target and calculate a delta, starting from patch series v2.

> Lastly, I don't think I see in the current patch series where you add new
> testsuite coverage for aarch64-specific bits.  I probably missed it, so feel free to
> helpfully correct me there :)  I'd be curious to see how the tests were written to
> take into account target differences (using for example the dejagnu feature
> procs) and other nuances.

Tests have not been added yet. This does not mean they do not exist
or are not used. They are implemented and used in our CI, and will be
contributed to the aarch64-w64-mingw32 target in the next patch
series.
https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build/tree/main/tests


Regards,
Evgeny

[PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[Evgeny Karpov]

Wednesday, February 28, 2024 2:00 AM
Andrew Pinski wrote:

> What does this mean with respect to C++ exceptions? Or you using SJLJ
> exceptions support or the dwarf unwinding ones without SEH support?
> I am not sure if SJLJ exceptions is well tested any more in GCC either.
> 
> Also I have a question if you ran the full GCC/G++ testsuites and what were the
> results?
> If you did run it, did you use a cross compiler or the native compiler? Did you
> do a bootstrap (GCC uses C++ but no exceptions though)?

As mentioned in the cover letter and the thread, the current
contribution covers only the C scope.
Exception handling is fully disabled for now.
There is an experimental build with C++ and SEH, however, it
is not included in the plan for the current contribution.

https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build

> If you run using a cross compiler, did you use ssh or some other route to run
> the applications?
> 
> Thanks,
> Andrew Pinski

GitHub Actions are used to cross-compile toolchains, packages
and tests, and execute tests on Windows Arm64.

https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build/actions/runs/7929205044

Regards,
Evgeny

RE: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[Andrew Pinski (QUIC)]

> -----Original Message-----
> From: Evgeny Karpov <Evgeny.Karpov@microsoft.com>
> Sent: Thursday, February 29, 2024 8:46 AM
> To: Andrew Pinski <pinskia@gmail.com>
> Cc: Richard Sandiford <richard.sandiford@arm.com>; gcc-
> patches@gcc.gnu.org; 10walls@gmail.com; Maxim Kuvyrkov
> <maxim.kuvyrkov@linaro.org>; mark@harmstone.com; Zac Walker
> <zacwalker@microsoft.com>; Ron Riddle <Ron.Riddle@microsoft.com>; Radek
> Barton <radek.barton@microsoft.com>; Andrew Pinski (QUIC)
> <quic_apinski@quicinc.com>
> Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments
> for AArch64
> 
> Wednesday, February 28, 2024 2:00 AM
> Andrew Pinski wrote:
> 
> > What does this mean with respect to C++ exceptions? Or you using SJLJ
> > exceptions support or the dwarf unwinding ones without SEH support?
> > I am not sure if SJLJ exceptions is well tested any more in GCC either.
> >
> > Also I have a question if you ran the full GCC/G++ testsuites and what
> > were the results?
> > If you did run it, did you use a cross compiler or the native
> > compiler? Did you do a bootstrap (GCC uses C++ but no exceptions though)?
> 
> As mentioned in the cover letter and the thread, the current contribution
> covers only the C scope.
> Exception handling is fully disabled for now.
> There is an experimental build with C++ and SEH, however, it is not included in
> the plan for the current contribution.
> 
> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build
> 
> > If you run using a cross compiler, did you use ssh or some other route
> > to run the applications?
> >
> > Thanks,
> > Andrew Pinski
> 
> GitHub Actions are used to cross-compile toolchains, packages and tests, and
> execute tests on Windows Arm64.

This does not answer my question because what you are running is just simple testcases and not the FULL GCC testsuite.
So again have you ran the GCC testsuite and do you have a dejagnu board to be able to execute the binaries?
I think without the GCC testsuite ran to find all of the known failures, you are going to be running into many issues.
The GCC testsuite includes many tests for ABI corner cases and many features that you will most likely not think about testing using your simple testcases.
In fact I suspect there will be some of the aarch64 testcases which will need to be modified for the windows ABI which you have not done yet.


Thanks,
Andrew Pinski

> 
> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-
> build/actions/runs/7929205044
> 
> Regards,
> Evgeny

Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[Maxim Kuvyrkov]

> On Feb 29, 2024, at 21:35, Andrew Pinski (QUIC) <quic_apinski@quicinc.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Evgeny Karpov <Evgeny.Karpov@microsoft.com>
>> Sent: Thursday, February 29, 2024 8:46 AM
>> To: Andrew Pinski <pinskia@gmail.com>
>> Cc: Richard Sandiford <richard.sandiford@arm.com>; gcc-
>> patches@gcc.gnu.org; 10walls@gmail.com; Maxim Kuvyrkov
>> <maxim.kuvyrkov@linaro.org>; mark@harmstone.com; Zac Walker
>> <zacwalker@microsoft.com>; Ron Riddle <Ron.Riddle@microsoft.com>; Radek
>> Barton <radek.barton@microsoft.com>; Andrew Pinski (QUIC)
>> <quic_apinski@quicinc.com>
>> Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments
>> for AArch64
>> 
>> Wednesday, February 28, 2024 2:00 AM
>> Andrew Pinski wrote:
>> 
>>> What does this mean with respect to C++ exceptions? Or you using SJLJ
>>> exceptions support or the dwarf unwinding ones without SEH support?
>>> I am not sure if SJLJ exceptions is well tested any more in GCC either.
>>> 
>>> Also I have a question if you ran the full GCC/G++ testsuites and what
>>> were the results?
>>> If you did run it, did you use a cross compiler or the native
>>> compiler? Did you do a bootstrap (GCC uses C++ but no exceptions though)?
>> 
>> As mentioned in the cover letter and the thread, the current contribution
>> covers only the C scope.
>> Exception handling is fully disabled for now.
>> There is an experimental build with C++ and SEH, however, it is not included in
>> the plan for the current contribution.
>> 
>> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build
>> 
>>> If you run using a cross compiler, did you use ssh or some other route
>>> to run the applications?
>>> 
>>> Thanks,
>>> Andrew Pinski
>> 
>> GitHub Actions are used to cross-compile toolchains, packages and tests, and
>> execute tests on Windows Arm64.
> 
> This does not answer my question because what you are running is just simple testcases and not the FULL GCC testsuite.
> So again have you ran the GCC testsuite and do you have a dejagnu board to be able to execute the binaries?
> I think without the GCC testsuite ran to find all of the known failures, you are going to be running into many issues.
> The GCC testsuite includes many tests for ABI corner cases and many features that you will most likely not think about testing using your simple testcases.
> In fact I suspect there will be some of the aarch64 testcases which will need to be modified for the windows ABI which you have not done yet.

Hi Andrew,

We (Linaro) have a prototype CI loop setup for testing aarch64-w64-mingw32, and we have results for gcc-c and libatomic -- see [1].

The results are far from clean, but that's expected.  This patch series aims at enabling C hello-world only, and subsequent patch series will improve the state of the port.

[1] https://ci.linaro.org/job/tcwg_gnu_mingw_check_gcc--master-woa64-build/6/artifact/artifacts/sumfiles/

Thanks,

--
Maxim Kuvyrkov
https://www.linaro.org

RE: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[Andrew Pinski (QUIC)]

> -----Original Message-----
> From: Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
> Sent: Thursday, February 29, 2024 9:46 AM
> To: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
> Cc: Evgeny Karpov <Evgeny.Karpov@microsoft.com>; Andrew Pinski
> <pinskia@gmail.com>; Richard Sandiford <richard.sandiford@arm.com>; gcc-
> patches@gcc.gnu.org; 10walls@gmail.com; mark@harmstone.com; Zac
> Walker <zacwalker@microsoft.com>; Ron Riddle
> <Ron.Riddle@microsoft.com>; Radek Barton <radek.barton@microsoft.com>
> Subject: Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW
> environments for AArch64
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> > On Feb 29, 2024, at 21:35, Andrew Pinski (QUIC)
> <quic_apinski@quicinc.com> wrote:
> >
> >
> >
> >> -----Original Message-----
> >> From: Evgeny Karpov <Evgeny.Karpov@microsoft.com>
> >> Sent: Thursday, February 29, 2024 8:46 AM
> >> To: Andrew Pinski <pinskia@gmail.com>
> >> Cc: Richard Sandiford <richard.sandiford@arm.com>; gcc-
> >> patches@gcc.gnu.org; 10walls@gmail.com; Maxim Kuvyrkov
> >> <maxim.kuvyrkov@linaro.org>; mark@harmstone.com; Zac Walker
> >> <zacwalker@microsoft.com>; Ron Riddle <Ron.Riddle@microsoft.com>;
> >> Radek Barton <radek.barton@microsoft.com>; Andrew Pinski (QUIC)
> >> <quic_apinski@quicinc.com>
> >> Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments
> >> for AArch64
> >>
> >> Wednesday, February 28, 2024 2:00 AM
> >> Andrew Pinski wrote:
> >>
> >>> What does this mean with respect to C++ exceptions? Or you using
> >>> SJLJ exceptions support or the dwarf unwinding ones without SEH
> support?
> >>> I am not sure if SJLJ exceptions is well tested any more in GCC either.
> >>>
> >>> Also I have a question if you ran the full GCC/G++ testsuites and
> >>> what were the results?
> >>> If you did run it, did you use a cross compiler or the native
> >>> compiler? Did you do a bootstrap (GCC uses C++ but no exceptions
> though)?
> >>
> >> As mentioned in the cover letter and the thread, the current
> >> contribution covers only the C scope.
> >> Exception handling is fully disabled for now.
> >> There is an experimental build with C++ and SEH, however, it is not
> >> included in the plan for the current contribution.
> >>
> >> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-
> build
> >>
> >>> If you run using a cross compiler, did you use ssh or some other
> >>> route to run the applications?
> >>>
> >>> Thanks,
> >>> Andrew Pinski
> >>
> >> GitHub Actions are used to cross-compile toolchains, packages and
> >> tests, and execute tests on Windows Arm64.
> >
> > This does not answer my question because what you are running is just
> simple testcases and not the FULL GCC testsuite.
> > So again have you ran the GCC testsuite and do you have a dejagnu board to
> be able to execute the binaries?
> > I think without the GCC testsuite ran to find all of the known failures, you are
> going to be running into many issues.
> > The GCC testsuite includes many tests for ABI corner cases and many
> features that you will most likely not think about testing using your simple
> testcases.
> > In fact I suspect there will be some of the aarch64 testcases which will need
> to be modified for the windows ABI which you have not done yet.
> 
> Hi Andrew,
> 
> We (Linaro) have a prototype CI loop setup for testing aarch64-w64-
> mingw32, and we have results for gcc-c and libatomic -- see [1].
> 
> The results are far from clean, but that's expected.  This patch series aims at
> enabling C hello-world only, and subsequent patch series will improve the
> state of the port.
> 
> [1] https://ci.linaro.org/job/tcwg_gnu_mingw_check_gcc--master-woa64-
> build/6/artifact/artifacts/sumfiles/

Looking at these results, this port is not in any shape or form to be upstreamed right now. Even simple -g will cause failures.
Note we don't need a clean testsuite run but the patch series is not even allowing enabling hello world due to the -g not being able to used.

Thanks,
Amdrew Pinski

> 
> Thanks,
> 
> --
> Maxim Kuvyrkov
> https://www.linaro.org

Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[Richard Earnshaw (lists)]

On 29/02/2024 17:55, Andrew Pinski (QUIC) wrote:
>> -----Original Message-----
>> From: Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
>> Sent: Thursday, February 29, 2024 9:46 AM
>> To: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
>> Cc: Evgeny Karpov <Evgeny.Karpov@microsoft.com>; Andrew Pinski
>> <pinskia@gmail.com>; Richard Sandiford <richard.sandiford@arm.com>; gcc-
>> patches@gcc.gnu.org; 10walls@gmail.com; mark@harmstone.com; Zac
>> Walker <zacwalker@microsoft.com>; Ron Riddle
>> <Ron.Riddle@microsoft.com>; Radek Barton <radek.barton@microsoft.com>
>> Subject: Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW
>> environments for AArch64
>>
>> WARNING: This email originated from outside of Qualcomm. Please be wary
>> of any links or attachments, and do not enable macros.
>>
>>> On Feb 29, 2024, at 21:35, Andrew Pinski (QUIC)
>> <quic_apinski@quicinc.com> wrote:
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Evgeny Karpov <Evgeny.Karpov@microsoft.com>
>>>> Sent: Thursday, February 29, 2024 8:46 AM
>>>> To: Andrew Pinski <pinskia@gmail.com>
>>>> Cc: Richard Sandiford <richard.sandiford@arm.com>; gcc-
>>>> patches@gcc.gnu.org; 10walls@gmail.com; Maxim Kuvyrkov
>>>> <maxim.kuvyrkov@linaro.org>; mark@harmstone.com; Zac Walker
>>>> <zacwalker@microsoft.com>; Ron Riddle <Ron.Riddle@microsoft.com>;
>>>> Radek Barton <radek.barton@microsoft.com>; Andrew Pinski (QUIC)
>>>> <quic_apinski@quicinc.com>
>>>> Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments
>>>> for AArch64
>>>>
>>>> Wednesday, February 28, 2024 2:00 AM
>>>> Andrew Pinski wrote:
>>>>
>>>>> What does this mean with respect to C++ exceptions? Or you using
>>>>> SJLJ exceptions support or the dwarf unwinding ones without SEH
>> support?
>>>>> I am not sure if SJLJ exceptions is well tested any more in GCC either.
>>>>>
>>>>> Also I have a question if you ran the full GCC/G++ testsuites and
>>>>> what were the results?
>>>>> If you did run it, did you use a cross compiler or the native
>>>>> compiler? Did you do a bootstrap (GCC uses C++ but no exceptions
>> though)?
>>>>
>>>> As mentioned in the cover letter and the thread, the current
>>>> contribution covers only the C scope.
>>>> Exception handling is fully disabled for now.
>>>> There is an experimental build with C++ and SEH, however, it is not
>>>> included in the plan for the current contribution.
>>>>
>>>> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-
>> build
>>>>
>>>>> If you run using a cross compiler, did you use ssh or some other
>>>>> route to run the applications?
>>>>>
>>>>> Thanks,
>>>>> Andrew Pinski
>>>>
>>>> GitHub Actions are used to cross-compile toolchains, packages and
>>>> tests, and execute tests on Windows Arm64.
>>>
>>> This does not answer my question because what you are running is just
>> simple testcases and not the FULL GCC testsuite.
>>> So again have you ran the GCC testsuite and do you have a dejagnu board to
>> be able to execute the binaries?
>>> I think without the GCC testsuite ran to find all of the known failures, you are
>> going to be running into many issues.
>>> The GCC testsuite includes many tests for ABI corner cases and many
>> features that you will most likely not think about testing using your simple
>> testcases.
>>> In fact I suspect there will be some of the aarch64 testcases which will need
>> to be modified for the windows ABI which you have not done yet.
>>
>> Hi Andrew,
>>
>> We (Linaro) have a prototype CI loop setup for testing aarch64-w64-
>> mingw32, and we have results for gcc-c and libatomic -- see [1].
>>
>> The results are far from clean, but that's expected.  This patch series aims at
>> enabling C hello-world only, and subsequent patch series will improve the
>> state of the port.
>>
>> [1] https://ci.linaro.org/job/tcwg_gnu_mingw_check_gcc--master-woa64-
>> build/6/artifact/artifacts/sumfiles/
> 
> Looking at these results, this port is not in any shape or form to be upstreamed right now. Even simple -g will cause failures.
> Note we don't need a clean testsuite run but the patch series is not even allowing enabling hello world due to the -g not being able to used.
> 

It seemed to me as though the patch was posted for comments, not for immediate inclusion.  I agree this isn't ready for committing yet, but neither should the submitters wait until it's perfect before posting it.

I think it's gcc-15 material, so now is about the right time to be thinking about it.

R.

> Thanks,
> Amdrew Pinski
> 
>>
>> Thanks,
>>
>> --
>> Maxim Kuvyrkov
>> https://www.linaro.org
> 

Re: [PATCH v1 00/13] Add aarch64-w64-mingw32 target

[NightStrike]

On Thu, Feb 29, 2024 at 11:26 AM Evgeny Karpov
<Evgeny.Karpov@microsoft.com> wrote:
>
> Monday, February 26, 2024 2:30 AM
> NightStrike wrote:
>
> > To be clear, because of the refactoring, it will affect x86/x64 Windows targets.
> > Can you do a testsuite run before and after and see that it doesn't get worse?
> > The full testsuite for all languages for Windows isn't in great shape, but it's not
> > awful.  Some languages, like Rust and Fortran, have ~10 FAILs.  C and C++ have
> > several thousand.
> >
> > In particular, there are quite a few testsuite test FAILs regarding MS ABI that
> > hopefully do not get worse.
> >
>
> Thank you for bringing it up! Our CI will be extended to test the x64
> mingw target and calculate a delta, starting from patch series v2.

Thanks.  You should probably include x86 also, at least for all the
areas that overlap.  I would like to compare my own test results with
yours when you have that ready.

You can send test results to the gcc mailing list setup for this
purpose: https://gcc.gnu.org/mailman/listinfo/gcc-testresults, and
there are scripts in contrib/ to help automate the process.  I
personally stopped, because the clusters I used had their mail sending
capabilities cut off, but I'm working on fixing that.

> > Lastly, I don't think I see in the current patch series where you add new
> > testsuite coverage for aarch64-specific bits.  I probably missed it, so feel free to
> > helpfully correct me there :)  I'd be curious to see how the tests were written to
> > take into account target differences (using for example the dejagnu feature
> > procs) and other nuances.
>
> Tests have not been added yet. This does not mean they do not exist
> or are not used. They are implemented and used in our CI, and will be
> contributed to the aarch64-w64-mingw32 target in the next patch
> series.
> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build/tree/main/tests

Awesome!  These tests look like they are handled by your own custom
test harness, so hopefully it won't be too difficult to convert it all
to dejagnu.  Honestly, the sooner you do that, the better, because the
task is going to balloon.  You'll find that Deja offers all kinds of
neat and useful features that allow you to test all kinds of things,
so it'll result in better coverage in the end.

[PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[Evgeny Karpov]

Thursday, February 29, 2024 6:56 PM
Andrew Pinski (QUIC) wrote:

> Looking at these results, this port is not in any shape or form to be upstreamed
> right now. Even simple -g will cause failures.
> Note we don't need a clean testsuite run but the patch series is not even
> allowing enabling hello world due to the -g not being able to used.
> 
> Thanks,
> Amdrew Pinski

For now, our contribution plan contains 4 patch series.

1. Minimal aarch64-w64-mingw32 C implementation to cross-compile
hello-world with libgcc for Windows Arm64 using MinGW.
2. Extension of the aarch64-w64-mingw32 C implementation to
cross-compile OpenSSL, OpenBLAS, FFmpeg, and libjpeg-turbo. All
packages successfully pass tests.
3. Addition of call stack support for debugging, resolution of
optimization issues in the C compiler, and DLL export/import for the
aarch64-w64-mingw32 target.
4. Unit testing integration for aarch64-w64-mingw32 target

The goal is to prepare the first patch series for upstreaming as
soon as possible. This will enable iterative development and
introduce a new target that can potentially be tested and
improved by the community.

If debugging information is a strong blocker for the first patch
series, its priority can be changed. However, it would be
preferable to include it in the second and third patch series,
as originally planned.

Regards,
Evgeny

[PATCH v1 00/13] Add aarch64-w64-mingw32 target

[Evgeny Karpov]

Thank you for the initial review for v1!

Work on refactoring, rebasing, and validating 
"[PATCH v2] Add aarch64-w64-mingw32 target" is in progress. 
The v2 x64 mingw target will also be fully tested to avoid
regression due to refactoring.
Please provide feedback if anything is missing.

Changes from v1 to v2:
Adjust the target name to aarch64-*-mingw* to exclude the 
big-endian target from support.
Exclude 64-bit ISA.
Rename enum calling_abi to aarch64_calling_abi.
Move AARCH64 MS ABI definitions FIXED_REGISTERS, 
CALL_REALLY_USED_REGISTERS, and STATIC_CHAIN_REGNUM from 
aarch64.h to aarch64-abi-ms.h.
Rename TARGET_ARM64_MS_ABI to TARGET_AARCH64_MS_ABI.
Exclude TARGET_64BIT from the aarch64 target.
Exclude HAVE_GAS_WEAK.
Set HAVE_GAS_ALIGNED_COMM to 1 by default.
Use a reference from "x86 Windows Options" to "Cygwin and MinGW Options".
Update commit descriptions to follow standard style.


Regards,
Evgeny

Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[Maxim Kuvyrkov]

> On Feb 29, 2024, at 21:59, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
> 
> On 29/02/2024 17:55, Andrew Pinski (QUIC) wrote:
>>> -----Original Message-----
>>> From: Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
>>> Sent: Thursday, February 29, 2024 9:46 AM
>>> To: Andrew Pinski (QUIC) <quic_apinski@quicinc.com>
>>> Cc: Evgeny Karpov <Evgeny.Karpov@microsoft.com>; Andrew Pinski
>>> <pinskia@gmail.com>; Richard Sandiford <richard.sandiford@arm.com>; gcc-
>>> patches@gcc.gnu.org; 10walls@gmail.com; mark@harmstone.com; Zac
>>> Walker <zacwalker@microsoft.com>; Ron Riddle
>>> <Ron.Riddle@microsoft.com>; Radek Barton <radek.barton@microsoft.com>
>>> Subject: Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW
>>> environments for AArch64
>>> 
>>> WARNING: This email originated from outside of Qualcomm. Please be wary
>>> of any links or attachments, and do not enable macros.
>>> 
>>>> On Feb 29, 2024, at 21:35, Andrew Pinski (QUIC)
>>> <quic_apinski@quicinc.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: Evgeny Karpov <Evgeny.Karpov@microsoft.com>
>>>>> Sent: Thursday, February 29, 2024 8:46 AM
>>>>> To: Andrew Pinski <pinskia@gmail.com>
>>>>> Cc: Richard Sandiford <richard.sandiford@arm.com>; gcc-
>>>>> patches@gcc.gnu.org; 10walls@gmail.com; Maxim Kuvyrkov
>>>>> <maxim.kuvyrkov@linaro.org>; mark@harmstone.com; Zac Walker
>>>>> <zacwalker@microsoft.com>; Ron Riddle <Ron.Riddle@microsoft.com>;
>>>>> Radek Barton <radek.barton@microsoft.com>; Andrew Pinski (QUIC)
>>>>> <quic_apinski@quicinc.com>
>>>>> Subject: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments
>>>>> for AArch64
>>>>> 
>>>>> Wednesday, February 28, 2024 2:00 AM
>>>>> Andrew Pinski wrote:
>>>>> 
>>>>>> What does this mean with respect to C++ exceptions? Or you using
>>>>>> SJLJ exceptions support or the dwarf unwinding ones without SEH
>>> support?
>>>>>> I am not sure if SJLJ exceptions is well tested any more in GCC either.
>>>>>> 
>>>>>> Also I have a question if you ran the full GCC/G++ testsuites and
>>>>>> what were the results?
>>>>>> If you did run it, did you use a cross compiler or the native
>>>>>> compiler? Did you do a bootstrap (GCC uses C++ but no exceptions
>>> though)?
>>>>> 
>>>>> As mentioned in the cover letter and the thread, the current
>>>>> contribution covers only the C scope.
>>>>> Exception handling is fully disabled for now.
>>>>> There is an experimental build with C++ and SEH, however, it is not
>>>>> included in the plan for the current contribution.
>>>>> 
>>>>> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-
>>> build
>>>>> 
>>>>>> If you run using a cross compiler, did you use ssh or some other
>>>>>> route to run the applications?
>>>>>> 
>>>>>> Thanks,
>>>>>> Andrew Pinski
>>>>> 
>>>>> GitHub Actions are used to cross-compile toolchains, packages and
>>>>> tests, and execute tests on Windows Arm64.
>>>> 
>>>> This does not answer my question because what you are running is just
>>> simple testcases and not the FULL GCC testsuite.
>>>> So again have you ran the GCC testsuite and do you have a dejagnu board to
>>> be able to execute the binaries?
>>>> I think without the GCC testsuite ran to find all of the known failures, you are
>>> going to be running into many issues.
>>>> The GCC testsuite includes many tests for ABI corner cases and many
>>> features that you will most likely not think about testing using your simple
>>> testcases.
>>>> In fact I suspect there will be some of the aarch64 testcases which will need
>>> to be modified for the windows ABI which you have not done yet.
>>> 
>>> Hi Andrew,
>>> 
>>> We (Linaro) have a prototype CI loop setup for testing aarch64-w64-
>>> mingw32, and we have results for gcc-c and libatomic -- see [1].
>>> 
>>> The results are far from clean, but that's expected.  This patch series aims at
>>> enabling C hello-world only, and subsequent patch series will improve the
>>> state of the port.
>>> 
>>> [1] https://ci.linaro.org/job/tcwg_gnu_mingw_check_gcc--master-woa64-
>>> build/6/artifact/artifacts/sumfiles/
>> 
>> Looking at these results, this port is not in any shape or form to be upstreamed right now. Even simple -g will cause failures.
>> Note we don't need a clean testsuite run but the patch series is not even allowing enabling hello world due to the -g not being able to used.
>> 
> 
> It seemed to me as though the patch was posted for comments, not for immediate inclusion.  I agree this isn't ready for committing yet, but neither should the submitters wait until it's perfect before posting it.
> 
> I think it's gcc-15 material, so now is about the right time to be thinking about it.

Hi Andrew,

I agree with Richard.  This patch series is large as is, and it has clear goals:
1. Enable aarch64-w64-mingw32 to compile C-language hello-world.
2. Not regress any other targets.

As far as I know, it achieves both, but both Microsoft and Linaro will do additional testing on x86_64-w64-mingw32 to confirm.

There are more features and fixes for aarch64-w64-mingw32 waiting in the development repos on github, but I don't see any point in cleaning them up and preparing for submission before this already-quiet-large patchset if reviewed.

Thank you,

--
Maxim Kuvyrkov
https://www.linaro.org