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 BFE213857C52; Wed, 6 Oct 2021 17:51:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BFE213857C52 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 196Hogu5025390; Wed, 6 Oct 2021 12:50:42 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 196HofYW025389; Wed, 6 Oct 2021 12:50:41 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 6 Oct 2021 12:50:41 -0500 From: Segher Boessenkool To: Jakub Jelinek Cc: 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: <20211006175041.GJ10333@gate.crashing.org> References: <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> <20211006165937.GI10333@gate.crashing.org> <20211006170743.GN304296@tucnak> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211006170743.GN304296@tucnak> 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 17:51:47 -0000 On Wed, Oct 06, 2021 at 07:07:43PM +0200, Jakub Jelinek wrote: > On Wed, Oct 06, 2021 at 11:59:37AM -0500, Segher Boessenkool wrote: > > On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek 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? > > > > On BE just as well. And on 32 bit. > > > > > But are those available everywhere where ppc64 is supported? For ppc32 > > > certainly not, I don't remember for ppc64. > > > > You can use VSX registers on 32 bit just fine. > > With -mvsx (or perhaps even -maltivec) sure, but if neither VSX nor Altivec > ISA is there... This was for -mcpu=power8 only. And yes, you can use -mno-vsx if you have p8 or later, which gives us the same issues as -msoft-float. > And having the ABI for long double dependent on whether one uses > -mvsx/-maltivec or not is a non-started. For generic vectors it is > something we decided to be acceptable... This is not about long double. This is about IEEE quad precision float. We need to make that work (on system X) before we can fathom using IEEE QP float as long double on system X. Working out what the parameter passing should be like is independent of what type is used for long double. -msoft-float has been a separate ABI always, of course. And so far QP float has not existed for powerpc64-linux. So we have three options (well, four): 0) Do nothing. We will stay in this hell forever. Not my choice :-) 1) Use a soft-float-like parameter passing everywhere. This works but will be horridly slow on newer systems. We can do better than that. 2) Use the current setup where -mcpu=power8 (or later) makes QP float available. Most BE stuff isn't compiled with that currently, and it will split our ecosystem. 3) As Joseph reminds me the high VSRs are the VRs, so we could use the same parameter passing on anything with AltiVec. We could even simply require -maltivec for QP float to be supported (we currently require -mvsx, this would not be a restriction). I think I like 3) :-) Segher