Message ID | VI1PR83MB04312A9E764DE743D605811BF8572@VI1PR83MB0431.EURPRD83.prod.outlook.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 513E53858437 for <patchwork@sourceware.org>; Wed, 21 Feb 2024 18:27:41 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2116.outbound.protection.outlook.com [40.107.20.116]) by sourceware.org (Postfix) with ESMTPS id B54193858D38 for <gcc-patches@gcc.gnu.org>; Wed, 21 Feb 2024 18:27:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B54193858D38 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=microsoft.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=microsoft.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B54193858D38 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.20.116 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1708540024; cv=pass; b=kZ4onyKuJBY1oixbsKc99noh3ceKwB4bvZRrKO7LXmLINqokZ8o6s5RL9d0P/9nzBjXNLQO8wzf6nXFwLrC3DqrolupUCh9ngUQFoCRh3PjmR84W6I0ct9CrlYUls3tpEi7zX0al65m6KFrG/vsnJ1XcNdEz2jTz8TH/ZYQsgn8= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1708540024; c=relaxed/simple; bh=5DhN8RbEpm9MpvlFHy2PoZfb8IU9puU5ceeOwqMO+Uo=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=WrwAs+b4lGV6aPtHtsnEkZ2uFup+sJ6SBNS/ALQ8ShlMgvWZXqwRbeKJ/5/alcfhKyNiZOaaRbM2TZionw3QoduPM1cwsPQzx4xi+ryi41UTjcODGomF9pfesbHvruiAIJleKOzV2pvaTORLBetqO7BJjPW0/gXisUsUYAjc3Qc= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oGogvyGHRdT7w3EObeWiO+zlWlN87xgLwckbyhsIQBPVMfd/q4NFQFLYXKAL6LTbblkgIezEXTVjTJ5bAIysy3Q6APJ9k7PUztaQSGScJM5IjO66r5Hz++VQpj0pTCJ5fmIPbuHwcku0lMbHZFY/NGoP7Qe+7XT92OtlvMrKkWfBnlE2SlYCR92UGVAUAP+lOsf12UEEFnenoB4P7jRBPJii+cJhbFfOGo3dBhQg+q86OuoCz+iSH3SLoldLj/xu0/2W9h/BoFUlG28czxZxDjCZTbCEBJusGWoGbIUnZis1pO6dxAh10yCqx+40y1sjiFZpdpcUQO/E//fVlNwBUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vZGL3eUYEkNO5M3u+z3xGUagdgc500csRoACoaNxSbY=; b=DD8cPFAtIEU2zi/dYVYVOZ8gKFes9J9TJVALzXY4TgmS8InCSjmUzPtWYC0L1UXIOsI35lcKVxn5Qwa7k+IqmDx6kBaE4yWek4nuFlvHs2Pke9bp6jriYZdZ/5qmFSxoxIygg494dPu0pFoB0qoUDuO12dZD5y1sDEQxDz1dj5ewY/rgHuwQaEHW7fKmIybEvKOROiyeGA/f+5QcVOuZiHk7kFErbcS2+VWuz46sQ5uwmA6weYIli8jGbPbt75IX8dNs+FKutcfvH1wuYR5+qikxpNmkuktNprSr/g3s6C/tzA1lnsUJWwtwwBkoPBflmobm7NGILJJl6D3+wnw/Kg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vZGL3eUYEkNO5M3u+z3xGUagdgc500csRoACoaNxSbY=; b=ZGgrXfQpQG6TbOToTZIl5uSSrrj+j1z7B4o9NAl9LgjVo1VaoPVS4/r6DaUGo7Rb0o/FF1cBngd1QxrV4VCKsd01Y87jS1luuNzQqwxTNdvKNYBHb4dAtTM4Y9hSjSn5TeKwQ3kgCZSHcqs8IE97fktV0VkeG9QZKAiledH6KIE= Received: from VI1PR83MB0431.EURPRD83.prod.outlook.com (2603:10a6:800:17f::6) by DBAPR83MB0407.EURPRD83.prod.outlook.com (2603:10a6:10:17c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.8; Wed, 21 Feb 2024 18:26:59 +0000 Received: from VI1PR83MB0431.EURPRD83.prod.outlook.com ([fe80::7279:eea0:8540:a0f5]) by VI1PR83MB0431.EURPRD83.prod.outlook.com ([fe80::7279:eea0:8540:a0f5%7]) with mapi id 15.20.7339.007; Wed, 21 Feb 2024 18:26:59 +0000 From: Evgeny Karpov <Evgeny.Karpov@microsoft.com> To: Evgeny Karpov <Evgeny.Karpov@microsoft.com>, "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org> CC: "richard.sandiford@arm.com" <richard.sandiford@arm.com>, "10walls@gmail.com" <10walls@gmail.com>, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>, "mark@harmstone.com" <mark@harmstone.com>, Zac Walker <zacwalker@microsoft.com>, Ron Riddle <Ron.Riddle@microsoft.com>, Radek Barton <radek.barton@microsoft.com> Subject: [PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements Thread-Topic: [PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements Thread-Index: AQHaZPOOrvtR4nxzOkKJZmV/dmRMNg== Date: Wed, 21 Feb 2024 18:26:59 +0000 Message-ID: <VI1PR83MB04312A9E764DE743D605811BF8572@VI1PR83MB0431.EURPRD83.prod.outlook.com> References: <VI1PR83MB04314E947B1CF296708085DDF8572@VI1PR83MB0431.EURPRD83.prod.outlook.com> In-Reply-To: <VI1PR83MB04314E947B1CF296708085DDF8572@VI1PR83MB0431.EURPRD83.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=57576bd1-751e-4189-ac11-c600ca5b612b; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2024-02-21T17:14:30Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: VI1PR83MB0431:EE_|DBAPR83MB0407:EE_ x-ms-office365-filtering-correlation-id: 504e6ab5-e25c-470d-40aa-08dc330ab11c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MdG2xyLCTjGA3818pYeg6GpkFWYPkeojs24kEo69V7aaavFcEgVargclUYor1C6xOYOB5OdE0IGwMiIbysns000tosUt46r/md9BO/k5qxw++Et71nJuSO4D1WtGUJHsANkxYQgD7NSTvZsFWVCmPI7KyPLFVAFHQ2AeFnZ1ZKP4jQspWpS/K4mPyTwemoOQRdPrb+242brEbkpLm1UfpNTRHHO3Hb/e71xkgf4jGaERdPgcwPRCmNHPrljPadAOaAPKeCrjsOIvvEXpOrsITXK0nnb8YtNTHq5amqAEd3wXPijqp7lLSjZaAW6OMM3Vfd66vvYN8NqesMh/PNW5btx6xEWybf4iSfH5BAVC9DE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR83MB0431.EURPRD83.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(38070700009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: q3djPAynWNttCAVL8txq6LNi5MVIZPWZG3arYbhJ8jpSfsY3T7dP0uVwUh/zS4GMFnnYilnKGam+Vxvh9SZ3hprnNfkDNLnEnBE3Hj01v0t5um+IM4UvVwEPKCWKO49iNR4u6cZcZd/waNHugAccEbO+fPjyyMQJUzbAiWDDVCSrfGIfjDb9IS+N0Gr3/H23UM3Y9s6lHHGCVgpCJk+9hfDQE/6jkChfAvVVissFk9lPWO0y8eiyn73PZaatOA7U+0t7LWzUMV0gn/IcP0vieJijSPH1xCEcYyvxcXPcqGHY0IJcblpGp7jn3NPLNzBLZsQn4oHjHhCjTmYmMbfl+FfoYC43Rv8LR0QqiL2kfuE+c7wUB5t3g5zUigMzLv5SfWoMyckSZNRULbvtY+CZATh6hSJ1lkvRleaW++FvO2/GCnYAR64pBSzJguS/USqHrKZNt98Xzf4minUoFL2BX6UWvUwZy5Uen/aZDupgHI9uv8+5SMWDtgp/Ycr33qIwJ1kqBfxC2g2kbI05BcBu8wzgBorCiFffND8yhzBhFYred9OHLZ2Y73EBjLqaKoQIzkTBu/+W1JQBu0wg5j/xKQFUb3X/USapOJKh7cKwknWs3GEOO23J0pHznXd/FC7tkVBVJDQ/BubT6AB4vQ+Xgu05mnTt2kRdH+jGzzRAWSoyvfBvT7MHo4bZAhVKQ1PiP7oC9pa40vk9Ut5TgweFsGmWH02QbdlluKVZIlpts1+RiYm015nhtsLtM4ioBqmdcP3djjUwmGS/IRCjMyxVhpj4L3R24YYQ+KK9someVqPVjYk27EvdjY/oxNlhCS3jUHPWCQmgLxrUJE3q+cSghA5jUbaiH9qcjxXfCorHRcKSPxLzq2B1UF7sCrLwEcbjO2rGDvSHRdBONAXDaNFYMUiOejMKpoDh8rrGQMqlVsqS53m8r6x+uFxtNYYc2HpiwFSbIw780JE94c+mV9r7lS1SXfMxY7jETsRgHOcOUgYk9leOrNnGdmdNqKymiNXAW801L4ZPxvHciCQn3f4hpHWmNKrPaj8iH1LWXVbpqPdRxusoUNOw0BGsXQg3uYv/YDx8YOfy/lrLCpfjOPgxeUjG0V1oq9+iptItzWp+O6oLmIcxR3xmVFveCUKg7lA3YOuEnNwAkxvqaIwzsJXDeop0hLEHByxz2Sp9SENLPgfk2UmU9pg7PsHFHZ/ylRyKxTz6vzfYehjS9SOb6sBT3fuVZE28OvUlA+bF7CooZrVQrazqtOH77Wz/ay9tI680LK65dp+zOZatZaF+eEaOY/tXkgBTDv0gQr0NM/0Khy+CuWVhH0h2bG9xgGkIpoGZVrd0zFvdKWaXPKwqI+9umBO7w1W9zUx8+bYzIZ/mIP9Cz/eT+XnQZ+Ig6KgEdKiVdWzy9LnEejZ2BiXRChuLhdNRB/Wo6ZgszVVgAzX6oz79DBagZz2R23DGIGUch7EYt7lmI55hS2FyC0f1h44O4Cv123RWfKzvH/eIpoZJPPOmrGvsTFyuJp2vQ/6rEkXNHr1qHZJt3Nn1rWDpRiXOnHCijZYBCUyVNN+4IsR3wFtFVT5dXvgo5a6N3tR6XEXT Content-Type: multipart/mixed; boundary="_002_VI1PR83MB04312A9E764DE743D605811BF8572VI1PR83MB0431EURP_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR83MB0431.EURPRD83.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 504e6ab5-e25c-470d-40aa-08dc330ab11c X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2024 18:26:59.3438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xak49gg/BDJOkei2EqwJE3gN9AIjCDm8MB0Ux2vXt4cXpQrE2+cVCODhPisV2OmHvxEhKeivSFVYdhUXG4Uvpw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR83MB0407 X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FORGED_SPF_HELO, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org |
Series |
Add aarch64-w64-mingw32 target
|
|
Commit Message
Evgeny Karpov
Feb. 21, 2024, 6:26 p.m. UTC
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(+)
Comments
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.
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.
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.
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.
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
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
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
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
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