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 95FF23858C39; Wed, 6 Oct 2021 20:58:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 95FF23858C39 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 196KvIsA004667; Wed, 6 Oct 2021 15:57:19 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 196KvHnH004664; Wed, 6 Oct 2021 15:57:17 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 6 Oct 2021 15:57:17 -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: <20211006205717.GL10333@gate.crashing.org> References: <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> <20211006183919.GK10333@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 20:58:24 -0000 On Wed, Oct 06, 2021 at 07:42:31PM +0000, Joseph Myers wrote: > On Wed, 6 Oct 2021, Segher Boessenkool wrote: > > Soft float is not described in any formal ABI btw (well, except the > > Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair. > > It's fully documented in the unified 32-bit ABI document (under > ATR-SOFT-FLOAT conditionals). That doc calls itself "Power Architecture® 32-bit Application Binary Interface Supplement 1.0 - Embedded". That is the exception I meant. Ignoring all the stuff I usually ignore it isn't very embedded, I agree, it is more or less what is powerpc-linux or powerpc-elf. With "not in any" I mean: not for other architectures either! All archs that do not say anything about floating point in their machine description get a working sofware floating point (for binary32 and binary64 currently). > There's still some code in the compiler for a very old soft-float ABI for > binary128 long double (passing by reference, using _q_* libcall names). I > don't really think it makes much sense to use that for future _Float128 > support for soft-float (certainly not the _q_* libcalls), rather than > passing in four consecutive GPRs as is done for IBM long double for soft > float, but we could. Maybe this harks back to POWER2 days? If so, we probably should just remove that code, we do not support anything else POWER2 anymore. If we want to implement soft-float for binary128, it would be best to do it the same for Power as for anything else. That of course means we have to *do* it for everything (or anything) else :-) And, as long as I'm creating more work, we could do binary16 and bfloat16 at the same time ;-) Segher