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 DE1DD3858C39; Wed, 6 Oct 2021 18:40:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DE1DD3858C39 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 196IdLSq028345; Wed, 6 Oct 2021 13:39:21 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 196IdJWp028344; Wed, 6 Oct 2021 13:39:19 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 6 Oct 2021 13:39:19 -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: <20211006183919.GK10333@gate.crashing.org> References: <20211004100754.GL304296@tucnak> <20211004141410.GP304296@tucnak> <6d845542-536e-1a0f-70e9-d05eea98aae7@netcologne.de> <20211005215450.GC10333@gate.crashing.org> <90df1250-9b3f-4a55-bc67-e3e05e54f7ef@netcologne.de> <20211006151744.GE10333@gate.crashing.org> <20211006154107.GK304296@tucnak> <20211006160730.GG10333@gate.crashing.org> <20211006163433.GM304296@tucnak> 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: Wed, 06 Oct 2021 18:40:27 -0000 On Wed, Oct 06, 2021 at 05:13:59PM +0000, Joseph Myers wrote: > On Wed, 6 Oct 2021, Jakub Jelinek via Gcc wrote: > > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote: > > > We can emulate it everywhere (using libquadmath for example). This can > > > magically make -msoft-float work as well everywhere, btw. > > > > Emulation is one thing, but another one is where are those __float128 or > > quad long double arguments and return values passed. On power8 le I think > > they are passed in VSX registers, aren't they? > > But are those available everywhere where ppc64 is supported? For ppc32 > > certainly not, I don't remember for ppc64. > > As noted in previous discussions, while the current GCC implementation > requires VSX for _Float128 support, the registers used in the ABI are the > same as AltiVec registers; it would be possible to implement support for > _Float128 on all powerpc64 with AltiVec (most but not all 64-bit > processors), using AltiVec registers in the ABI and being fully compatible > with the ABI using VSX registers. Good point. And we can simply require -maltivec for -mfloat128 to work. We currently require -mvsx, which itself requires -maltivec, so that is not a restriction. > > Sure, the ABI could say pass it in e.g. in a pair of integer registers... > > You'd need to decide whether you want the 64-bit BE ABI for _Float128 to > be one that supports the type on all 64-bit processors (so pass in integer > registers), or one that only supports it on processors with AltiVec but is > more similar to the LE ABI (passing in AltiVec registers). I vote for the latter: require -maltivec. Well unless -msoft-float perhaps, if someone ever cares enough to implement that for QP float :-) > And, then, decide the 32-bit ABIs (hard and soft float), if you want to > support _Float128 there. Soft float is not described in any formal ABI btw (well, except the Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair. Which does not work over function calls, but that is how it always has been. This never was a huge problem afaik. For 32-bit, maybe we can just require -maltivec as well, to allow -mfloat128? Or use what -msoft-float would do for _Float128, if -mno-altivec, if desired (this does not have to be limited to -m32 of course). > And, then, do glibc changes, both to support _Float128 functions at all, > and to support a different long double format if you wish to support > changing the long double format for those ABIs. Note that the symbol > versioning in glibc assumes that all libm functions either predate > _Float128 support on all architectures (version of *f128 versions is > FLOAT128_VERSION) or postdate it on all architectures (versions in > math/Versions based on whenever that function was added to glibc; various > *f64x functions, that alias *f128 when appropriate, are also hardcoded as > GLIBC_2.27). So if someone adds _Float128 support to any glibc ABI that > doesn't currently have it, they need to add support for new syntax in > Versions files such as MAX (FLOAT128_VERSION, GLIBC_2.28), which describes > the right symbol version for a _Float128 function added in 2.28, in the > case where some architecture gets _Float128 support later than that. And > likewise using LDBL_IBM128_VERSION for __*ieee128 aliases if you add > support for it being used as a new long double format. And adding the > support to glibc means increasing the minimum GCC version for building > glibc for those ABIs to one that supports _Float128 for those ABIs. Glibc is outside of my direct influence sphere ;-) This does sound like a reasonable plan to me though. Segher