From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id 22506385829A for ; Fri, 23 Feb 2024 17:54:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 22506385829A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 22506385829A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::1030 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708710871; cv=none; b=tBHlOZUau5QVfuOVyHOpinkQMWFUWgEN9F0uNZ+gPiJZHpE3fyw5yNxt4AUepBnY20G4TV7emB7GPevCqoNQFf40LNR8YFoOjAj9e1aH78WdKdkvXADExFQPqPsnWH/C9UkN5rjGHr99PLeY2csYHC2TpU+m3Sj1y7iHVkxrH+A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708710871; c=relaxed/simple; bh=SryJFOse/2gwd+rRI9w1h/G1IRx+WczuLPtdhAq0zY8=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=Am82YqdIRKFevt+8YFNPorQVuiUWur/8vlE/uN52L9ZGDAJPlAvlF9oczDkaSXMcS9zYfWL7ofdl+anDi7R9AlOvc2PC+LOEjMfXQVY6qhUSVNgDFEXWG60pC0JnfdFGbgyV5/FWW1NQSfjevaZfzcehlUfJwfyKzGWJzdIl5BY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-299566373d4so861311a91.1 for ; Fri, 23 Feb 2024 09:54:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708710868; x=1709315668; darn=gcc.gnu.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hgeBjGGYm8p9iGBtpe8cIA4KmVz76Utl5w6xl4hdSHU=; b=OxiwmUqNmb8ZxQZNAa4IdaOarse4Bt0B+FKNF6NyzauWynepP6ALIQksAt1+9Yytx4 uxCwvQhZTUn7rtIYsWOcD6vDv4MxZv8Fu/fn5LuFhjWJQXN1xPVbkZXj99YDcsC2bTH6 l0LNcHRU2IgElTl35ri/5zFUrPUUg2nCO1GLYChEkm4pnj01fMUi5Lzc8Y0ADiL1hPLs 2whQjbh3pZCL438a8HPH397RhN6nuG2IjoK8g/YYaKg6JqMuppSTmvUGjF85XUpZwrT1 eeOg+1/kyoUE9a9arIdJzAevD36VolkS6xy5V/Ho7tu9ZTjyUMqKEYxtaPLRCLbBXUZj UCng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708710868; x=1709315668; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hgeBjGGYm8p9iGBtpe8cIA4KmVz76Utl5w6xl4hdSHU=; b=lo0YyPRB7YSRL0YkrpKqiA78EQFwr0tKPseTzhfQJAYok1BnYMFuRlcXJHpcapkG0c BQMJ02t9N3+/tfTez5cvjNYa0xBIU8y/grrh5sp+bh/Xzb7pntxCRv4/T15M0X67FlNt 6kcPOAL96jZ4Sgcx1SBHqDSaVYPtDKFoXBq5CA0iCo8XQWsOBc9x6sV7jam1xB5WZYBD EbrDPkp9YYGewyTfdfwRASDVENfsp91vG1biTaMEAAMMZIa+x/h7XTcUKcDSkKMvntpc a67HkgFPSCpYvcKnNe32Isb/mnz4F8G34Sm0/BJkJ/MLDBZc5Yz5EgyTY5rn0WHqfubA kdHw== X-Forwarded-Encrypted: i=1; AJvYcCVDCsEhDgsolRdUgX72D6O3RcXmrde8Ax8JVCUH0vbNfaV3yhyF87sJe8SXuLe00d+nGcEePgh4OU1BErjJn4MZG6/R0UqjMg== X-Gm-Message-State: AOJu0Yz7SpuOWMeKjcfPHKTZohTHJWZElhDTPfzo6pdCP7ENCWgVKi/p sHUW4cu/aLHnDU6YM7Bf5OxRJPpPSPAxLHL5gUkUMjPemU21yD4pf058qia+aO2f8/60GlHqTQe mL9q06lFrZftNjNacDy0aCnhWdiY= X-Google-Smtp-Source: AGHT+IG+msB8dtPj+G/qTL9q+34dUrgD78zu+NGgV19Q8AtLMAAvL31puzd3F0IjJPG9k+WleAWSdCbB5APyJPe2yo8= X-Received: by 2002:a17:90a:de91:b0:299:29dc:839e with SMTP id n17-20020a17090ade9100b0029929dc839emr562393pjv.26.1708710867913; Fri, 23 Feb 2024 09:54:27 -0800 (PST) MIME-Version: 1.0 References: <9cd85535-b65b-4be7-9d40-a4e49c72e553@arm.com> In-Reply-To: From: Andrew Pinski Date: Fri, 23 Feb 2024 09:54:15 -0800 Message-ID: Subject: Re: [PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements To: Evgeny Karpov , "Richard Earnshaw (lists)" , "gcc-patches@gcc.gnu.org" , "10walls@gmail.com" <10walls@gmail.com>, Maxim Kuvyrkov , "mark@harmstone.com" , Zac Walker , Ron Riddle , Radek Barton , richard.sandiford@arm.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_MANYTO,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 List-Id: On Fri, Feb 23, 2024 at 9:51=E2=80=AFAM Richard Sandiford wrote: > > Evgeny Karpov writes: > > The calling ABI enum definition has been done following a similar conve= ntion in > > https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dblob;f=3Dgcc/config/i386/i386-= opts.h;h=3Def2825803b32001b9632769bdff196d1e43d27ba;hb=3Drefs/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=3Dgcc.git;a=3Dblob;f=3Dgcc/config/i386/mingw= 32.h;h=3D58304fc55f629648e47490fd3c0f3db3858e4fd8;hb=3Drefs/heads/master#l2= 2 > > > > 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 =3D 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 =3D=3D MS_A= BI) \ > gcc/config/mingw/winnt-d.cc: if (TARGET_64BIT && ix86_abi =3D=3D 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=3Dmsvc-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 =3D 0, > > + MS_ABI =3D 1 > > +}; > > + > > > > The convention in this file seems to be that all enum types to start wi= th 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.