| Message ID | VI1PR83MB0431419E005585F08F7EB445F8232@VI1PR83MB0431.EURPRD83.prod.outlook.com |
|---|---|
| Headers | show |
| Series | Add aarch64-w64-mingw32 target | expand |
gcc/ChangeLog: * config.gcc: * config/aarch64/aarch64-opts.h (enum aarch64_calling_abi): * config/aarch64/aarch64-protos.h (mingw_pe_maybe_record_exported_symbol): (mingw_pe_section_type_flags): (mingw_pe_unique_section): (mingw_pe_encode_section_info): * config/aarch64/aarch64.h (struct seh_frame_state): (GTY): * config/i386/cygming.h (SUBTARGET_ENCODE_SECTION_INFO): (TARGET_ASM_UNIQUE_SECTION): (TARGET_ASM_NAMED_SECTION): (TARGET_SECTION_TYPE_FLAGS): (ASM_DECLARE_COLD_FUNCTION_NAME): (ASM_OUTPUT_EXTERNAL_LIBCALL): * config/i386/i386-protos.h (i386_pe_unique_section): (i386_pe_declare_function_type): (mingw_pe_unique_section): (mingw_pe_declare_function_type): (i386_pe_maybe_record_exported_symbol): (i386_pe_encode_section_info): (mingw_pe_maybe_record_exported_symbol): (mingw_pe_encode_section_info): (i386_pe_section_type_flags): (i386_pe_asm_named_section): (mingw_pe_section_type_flags): (mingw_pe_asm_named_section): * config/i386/mingw-w64.opt.urls: * config/lynx.opt.urls: * config/i386/cygming.opt: Move to... * config/mingw/cygming.opt: ...here. * config/i386/cygwin-d.cc: Move to... * config/mingw/cygwin-d.cc: ...here. * config/i386/mingw-stdint.h: Move to... * config/mingw/mingw-stdint.h: ...here. * config/i386/mingw.opt: Move to... * config/mingw/mingw.opt: ...here. * config/i386/mingw.opt.urls: Move to... * config/mingw/mingw.opt.urls: ...here. * config/i386/mingw32.h: Move to... * config/mingw/mingw32.h: ...here. * config/i386/msformat-c.cc: Move to... * config/mingw/msformat-c.cc: ...here. * config/i386/t-cygming: Move to... * config/mingw/t-cygming: ...here. * config/i386/winnt-cxx.cc: Move to... * config/mingw/winnt-cxx.cc: ...here. * config/i386/winnt-d.cc: Move to... * config/mingw/winnt-d.cc: ...here. * config/i386/winnt-stubs.cc: Move to... * config/mingw/winnt-stubs.cc: ...here. * config/i386/winnt.cc: Move to... * config/mingw/winnt.cc: ...here. * doc/invoke.texi: * varasm.cc (switch_to_comdat_section): * config/i386/cygming.opt.urls: Removed. * config/aarch64/aarch64-abi-ms.h: New file. * config/aarch64/aarch64-coff.h: New file. * config/aarch64/cygming.h: New file. * config/mingw/cygming.opt.urls: New file. libatomic/ChangeLog: * configure.tgt: libgcc/ChangeLog: * config.host: * config/i386/t-gthr-win32: Move to... * config/mingw/t-gthr-win32: ...here. * config/i386/t-mingw-pthread: Move to... * config/mingw/t-mingw-pthread: ...here. * config/aarch64/t-no-eh: New file.
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-abi-ms.h | 64 +++++++
gcc/config/aarch64/aarch64-coff.h | 91 +++++++++
gcc/config/aarch64/aarch64-opts.h | 7 +
gcc/config/aarch64/aarch64-protos.h | 5 +
gcc/config/aarch64/aarch64.h | 6 +
gcc/config/aarch64/cygming.h | 175 ++++++++++++++++++
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 | 9 +-
gcc/config/{i386 => mingw}/mingw.opt | 0
gcc/config/{i386 => mingw}/mingw.opt.urls | 2 +-
gcc/config/{i386 => mingw}/mingw32.h | 6 +-
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
33 files changed, 510 insertions(+), 93 deletions(-)
create mode 100644 gcc/config/aarch64/aarch64-abi-ms.h
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 (86%)
rename gcc/config/{i386 => mingw}/mingw.opt (100%)
rename gcc/config/{i386 => mingw}/mingw.opt.urls (86%)
rename gcc/config/{i386 => mingw}/mingw32.h (98%)
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%)
Monday, March 4, 2024 Evgeny Karpov wrote: > > 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. > Rebase from 4th March 2024. Hello, It looks like the initial feedback has been addressed. While unit testing for the x86_64-w64-mingw32 target is still in progress, the first 4 patches do not obviously change other targets, including aarch64-linux-gnu. Could they be merged once stage 1 starts, or could it be done even now? Thanks! Regards, Evgeny
On Thu, 7 Mar 2024 at 21:48, Evgeny Karpov <Evgeny.Karpov@microsoft.com> wrote: > > Monday, March 4, 2024 > Evgeny Karpov wrote: > > > > > 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. > > Rebase from 4th March 2024. > > Hello, > > It looks like the initial feedback has been addressed. I had a look at the v2 series, and besides a minor comment patch #8, ISTM than all the comments your received about v1 have been addressed, indeed. > While unit testing for the x86_64-w64-mingw32 target is still in > progress, the first 4 patches do not obviously change other > targets, including aarch64-linux-gnu. > Could they be merged once stage 1 starts, > or could it be done even now? What would be the benefit of committing only the first 4 patches? (whether now or when stage 1 reopens) Thanks, Christophe > Thanks! > > Regards, > Evgeny >
Hello, everyone. Currently, we are able to provide results of regression testing for `x86_64-w64-mingw32` target with `--enable-languages=c,lto,c++,fortran` running in WSL only. The summarized results, both for the branch with patch set applied and its corresponding base branch, show: 517501 expected passes 4537 of expected failures 10828 unexpected failures 180 of unexpected successes 5934 of unresolved testcases 19113 of unsupported tests which means that 98% of the tests ends in an expected way and we haven't detected a single regression between the branches. The detailed results can be downloaded and reviewed at https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build/actions/runs/8327889403 Best regards, Radek Bartoň
Monday, March 18, 2024 2:34 PM Christophe Lyon wrote: > I had a look at the v2 series, and besides a minor comment patch #8, ISTM than > all the comments your received about v1 have been addressed, indeed. > > > While unit testing for the x86_64-w64-mingw32 target is still in > > progress, the first 4 patches do not obviously change other targets, > > including aarch64-linux-gnu. > > Could they be merged once stage 1 starts, or could it be done even > > now? > > What would be the benefit of committing only the first 4 patches? > (whether now or when stage 1 reopens) > > Thanks, > > Christophe Work on obtaining regression test results for x86_x64-w64-mingw32 was still in progress at that moment. The first 4 patches do not obviously change other targets, so it was safe to merge them. Now, based on the regression test results https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647967.html, it appears safe to merge the entire series. Regards, Evgeny
On Mon, Mar 18, 2024 at 3:10 PM Evgeny Karpov <Evgeny.Karpov@microsoft.com> wrote: > > > Monday, March 18, 2024 2:34 PM > Christophe Lyon wrote: > > > I had a look at the v2 series, and besides a minor comment patch #8, ISTM than > > all the comments your received about v1 have been addressed, indeed. > > > > > While unit testing for the x86_64-w64-mingw32 target is still in > > > progress, the first 4 patches do not obviously change other targets, > > > including aarch64-linux-gnu. > > > Could they be merged once stage 1 starts, or could it be done even > > > now? > > > > What would be the benefit of committing only the first 4 patches? > > (whether now or when stage 1 reopens) > > > > Thanks, > > > > Christophe > > Work on obtaining regression test results for x86_x64-w64-mingw32 was still in progress at that moment. > The first 4 patches do not obviously change other targets, so it was safe to merge them. > Now, based on the regression test results https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647967.html, > it appears safe to merge the entire series. > > Regards, > Evgeny LLVM has had an aarch64 mingw ABI support for a long time. Does this patch series introduce a different ABI? If yes, do you have a summary? Does the patch need any adaptation on the LLVM side, or should a different target triple be picked? I have always been wondering what "32" in "x86_x64-w64-mingw32" means. https://github.com/llvm/llvm-project/pull/78908 even introduced the first use of the triple "arm64ec-w64-mingw32" into llvm-project.
On Mon, Mar 18, 2024 at 3:59 PM Fangrui Song <maskray@google.com> wrote: > > On Mon, Mar 18, 2024 at 3:10 PM Evgeny Karpov > <Evgeny.Karpov@microsoft.com> wrote: > > > > > > Monday, March 18, 2024 2:34 PM > > Christophe Lyon wrote: > > > > > I had a look at the v2 series, and besides a minor comment patch #8, ISTM than > > > all the comments your received about v1 have been addressed, indeed. > > > > > > > While unit testing for the x86_64-w64-mingw32 target is still in > > > > progress, the first 4 patches do not obviously change other targets, > > > > including aarch64-linux-gnu. > > > > Could they be merged once stage 1 starts, or could it be done even > > > > now? > > > > > > What would be the benefit of committing only the first 4 patches? > > > (whether now or when stage 1 reopens) > > > > > > Thanks, > > > > > > Christophe > > > > Work on obtaining regression test results for x86_x64-w64-mingw32 was still in progress at that moment. > > The first 4 patches do not obviously change other targets, so it was safe to merge them. > > Now, based on the regression test results https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647967.html, > > it appears safe to merge the entire series. > > > > Regards, > > Evgeny > > LLVM has had an aarch64 mingw ABI support for a long time. Does this > patch series introduce a different ABI? > If yes, do you have a summary? > > Does the patch need any adaptation on the LLVM side, or should a > different target triple be picked? > I have always been wondering what "32" in "x86_x64-w64-mingw32" means. It was always mingw32, it comes from win32 API interface which dates to when windows also a 16bit API too. The API has always been named win32 and Microsoft didn't rename it to win64 though. Thanks, Andrew Pinski > > https://github.com/llvm/llvm-project/pull/78908 even introduced the > first use of the triple "arm64ec-w64-mingw32" into llvm-project. > > > -- > 宋方睿
On Mon, 18 Mar 2024, Fangrui Song wrote: > LLVM has had an aarch64 mingw ABI support for a long time. Does this > patch series introduce a different ABI? > If yes, do you have a summary? This patchset in itself does not reach ABI compatibility with the preexisting aarch64 mingw ecosystem - but this is also just the first patchset to lay out the groundwork for a new mingw target within GCC. As far as I've understood, the divergence is not intended, and they are working on converging towards compatibility - but such bits are to be handled in later patchsets. Off the top of my head, the major missing pieces wrt compatbility are the variadic calling convention, and using 64 bit doubles for "long double" (just like for Darwin). > Does the patch need any adaptation on the LLVM side, or should a > different target triple be picked? No, I don't think a different target triple should be used - it is intended to be the same, but compatibility is a work in progress. > I have always been wondering what "32" in "x86_x64-w64-mingw32" means. (Nit, I presume you meant "x86_64-w64-mingw32".) As Andrew replied, w32 stands for win32, which isn't so much about the bitness as "the current windows API as of the last 30 years, as opposed to win16". So it's more of a name than something indicating any form of bitness. Likewise, "w64" just indicates which vendor/fork is involved, so we also have i686-w64-mingw32 and armv7-w64-mingw32, for the 32 bit ABIs with an SDK from the same vendor. > https://github.com/llvm/llvm-project/pull/78908 even introduced the > first use of the triple "arm64ec-w64-mingw32" into llvm-project. ARM64EC is a totally different thing though; that's an entirely separate ABI on almost every single level. // Martin
Hello, everyone. I've re-run the `x86_64-w64-mingw32` target tests with all the languages enabled, except of Ada and JIT, which are harder to bootstrap, and Go, which is not supported by MinGW. The summarized results are: 536176 of expected passes 13859 of unexpected failures 188 of unexpected successes 4537 of expected failures 8271 of unresolved testcases 20958 of unsupported tests 97.40% of tests completes in expected way and, again, zero regressions were detected. The detailed results can be reviewed at https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build/actions/runs/8349019387 Best regards, Radek Bartoň
On Wed, Mar 20, 2024, 07:50 Radek Barton <radek.barton@microsoft.com> wrote: > Hello, everyone. > > I've re-run the `x86_64-w64-mingw32` target tests with all the languages > enabled, except of Ada and JIT, which are harder to bootstrap, and Go, > which is not supported by MinGW. The summarized results are: > > 536176 of expected passes > 13859 of unexpected failures > 188 of unexpected successes > 4537 of expected failures > 8271 of unresolved testcases > 20958 of unsupported tests > 97.40% of tests completes in expected way > You can generate an integrated summary using dejagnu report card: https://www.gnu.org/software/dejagnu/manual/Invoking-dejagnu-report-card.html > and, again, zero regressions were detected. > > The detailed results can be reviewed at > https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build/actions/runs/8349019387 > > Best regards, > > Radek Bartoň > > ________________________________________ > From: Radek Barton <radek.barton@microsoft.com> > Sent: Monday, March 18, 2024 10:05 PM > To: Evgeny Karpov; gcc-patches@gcc.gnu.org > Cc: richard.sandiford@arm.com; Richard Earnshaw (lists); Andrew Pinski > (QUIC); Maxim Kuvyrkov > Subject: Re: [PATCH v2 00/13] Add aarch64-w64-mingw32 target > > Hello, everyone. > > Currently, we are able to provide results of regression testing for > `x86_64-w64-mingw32` target with `--enable-languages=c,lto,c++,fortran` > running in WSL only. > > The summarized results, both for the branch with patch set applied and its > corresponding base branch, show: > > 517501 expected passes > 4537 of expected failures > 10828 unexpected failures > 180 of unexpected successes > 5934 of unresolved testcases > 19113 of unsupported tests > > which means that 98% of the tests ends in an expected way and we haven't > detected a single regression between the branches. > > The detailed results can be downloaded and reviewed at > https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build/actions/runs/8327889403 > > Best regards, > > Radek Bartoň >
Evgeny Karpov <Evgeny.Karpov@microsoft.com> writes: > Hello, > > v2 is ready for the review! > Based on the v1 review: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/thread.html#646203 > > Testing for the x86_64-w64-mingw32 target is in progress to avoid > regression due to refactoring. Thanks for the updates and sorry again for the slow review. I've replied to some of the patches in the series but otherwise it looks good to me. If you agree with the suggested changes then the series is OK for stage 1, assuming no objections from those with an interest in the x86 cygwin/mingw port. Richard > Regards, > Evgeny > > > 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. > Rebase from 4th March 2024.
Wednesday, April 10, 2024 8:40 PM Richard Sandiford <richard.sandiford@arm.com> wrote: > Thanks for the updates and sorry again for the slow review. > I've replied to some of the patches in the series but otherwise it looks good to > me. > > If you agree with the suggested changes then the series is OK for stage 1, > assuming no objections from those with an interest in the > x86 cygwin/mingw port. > > Richard Thank you, Richard, for the review! v3 addresses all comments on v2. https://gcc.gnu.org/pipermail/gcc-patches/2024-April/thread.html#649261 Regards, Evgeny
Evgeny Karpov <Evgeny.Karpov@microsoft.com> writes: > Wednesday, April 10, 2024 8:40 PM > Richard Sandiford <richard.sandiford@arm.com> wrote: > >> Thanks for the updates and sorry again for the slow review. >> I've replied to some of the patches in the series but otherwise it looks good to >> me. >> >> If you agree with the suggested changes then the series is OK for stage 1, >> assuming no objections from those with an interest in the >> x86 cygwin/mingw port. >> >> Richard > > Thank you, Richard, for the review! > v3 addresses all comments on v2. > https://gcc.gnu.org/pipermail/gcc-patches/2024-April/thread.html#649261 Thanks, the new series looks good to me. Richard