From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by sourceware.org (Postfix) with ESMTPS id 03E9D3858C35 for ; Tue, 19 Mar 2024 07:50:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 03E9D3858C35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=martin.st Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=martin.st ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 03E9D3858C35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=77.234.108.134 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710834612; cv=none; b=n+LFEKIprVfPTbUzzMwh0r+Mm2R2/oUlG6hJ6Gcsgb8isKUJrmKLd3u969weXhcjap1Dj5MtowQGxZ0/xAQC6oOYIv3E/lJtILtRkMuH3C8RK3vGIzZITug3JiIWlh75pcXuAy176Hkaihst7N8gySEvxZfvhvlTRD8kCfck66Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710834612; c=relaxed/simple; bh=uoR9cX+O0r/IUBHxwOhPgHgo2GwNohmTAsHG9qjUTAc=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=FvvQUckzWGTYZ1dlZ6qP4hiQByuUpIhAI4IrNTfkb3rEV7q8XoYEYfTzUecqQVcKWxPAy1FfLLxkdnGvv/Fmtl0CppM0PziotLgY90KapfYkRc6NMaCgp55MP/VC3wPHw+7gC1drQMyEPhyI4wUtxiU1g/ZNgihWu40UfN8uhCI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 42J7o3pD006872-42J7o3pE006872; Tue, 19 Mar 2024 09:50:03 +0200 Received: from cone.home.martin.st (host-114-191.parnet.fi [77.234.114.191]) by mail9.parnet.fi (Postfix) with ESMTPS id B2921A1467; Tue, 19 Mar 2024 09:50:02 +0200 (EET) Date: Tue, 19 Mar 2024 09:50:01 +0200 (EET) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: Fangrui Song cc: Evgeny Karpov , "gcc-patches@gcc.gnu.org" , "richard.sandiford@arm.com" , "Richard Earnshaw (lists)" , "christophe.lyon@linaro.org" , "Andrew Pinski (QUIC)" , Maxim Kuvyrkov , Radek Barton Subject: Re: [PATCH v2 00/13] Add aarch64-w64-mingw32 target In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-FEAS-Client-IP: 77.234.108.21 X-FE-Last-Public-Client-IP: 77.234.108.21 X-FE-Policy-ID: 3:14:2:SYSTEM X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_DNSWL_LOW,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 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