From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 7ACC23858433; Fri, 15 Oct 2021 00:18:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7ACC23858433 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 19F0GuqG004958; Thu, 14 Oct 2021 19:16:56 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 19F0Gsim004952; Thu, 14 Oct 2021 19:16:54 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 14 Oct 2021 19:16:54 -0500 From: Segher Boessenkool To: Joseph Myers Cc: Jakub Jelinek , Michael Meissner , gcc@gcc.gnu.org, Thomas Koenig , fortran@gcc.gnu.org, Tobias Burnus , Jonathan Wakely Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes Message-ID: <20211015001654.GI614@gate.crashing.org> References: <20211006154107.GK304296@tucnak> <20211006160730.GG10333@gate.crashing.org> <20211006163433.GM304296@tucnak> <20211006183919.GK10333@gate.crashing.org> <20211006205717.GL10333@gate.crashing.org> <20211008175335.GS10333@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 00:18:02 -0000 Hi! On Mon, Oct 11, 2021 at 08:11:50PM +0000, Joseph Myers wrote: > On Fri, 8 Oct 2021, Segher Boessenkool wrote: > > But many CPUs do not have hardware floating point in any variant, and > > their ABIs / calling conventions do not mention floating point at all. > > Still, this works with GCC just fine: it passes floats and doubles the > > same as 32-bit resp. 64-bit integers. > > > > binary16 and bfloat16 would be easy to support the same way, but it is a > > bit harder for binary128, because we do not have a 128-bit integer type > > Supporting passing arguments (and return values) the same as an integer > type of the same size is a *choice* (which comes with other choices - in > particular, whether to say some or all the higher bits in the register or > stack slot are sign-extended, zero-extended or undefined). It's a choice > that should be made explicitly, and documented (in the relevant ABI if one > is maintained), and coordinated between implementations when there's more > than one implementation for the architecture trying to be compatible. I don't disagree at all. But: GCC makes that choice for you, if you do not. Many (embedded and/or older) targets do not. They get the defaults, those just work, and /de facto/ become the standard. In practice most such architectures are purely 32-bit, so there is no sign/zero extension problem. > We've had plenty of problems in the past with ABIs that were just what > happened to fall out of the implementation (e.g. ABIs that depended on the > details of what machine mode was assigned to a structure type...). Yes. And we still have problems on older ABIs with e.g. new C++ requirements that did not exist >25 years ago when the ABIs were written. Not all of this can be helped at all. > On a related note, I'd encourage architecture maintainers to start > thinking now about what exactly their ABIs should be for _BitInt > (, accepted as > a required feature for C23 up to at least the width of unsigned long > long), and documenting it and coordinating with other implementations > where appropriate. There's a concrete proposal for x86_64 (see > origin/usr/hjl/bitint branch at > https://gitlab.com/x86-psABIs/x86-64-ABI.git) that may at least help as an > indication of the sort of issues to address in such an ABI. This should really go on gcc@, in a thread of its own, and a wiki page might help as well? Segher