From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 114FD3858C39; Wed, 6 Oct 2021 22:04:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 114FD3858C39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: RBGT4JCpd5r1ZOBIoFUAiCD89KkYlc3kzDQR6ceWC9AdsE4KkH6ED0U6tN9J8z+tQdYlNDGmGv RXP2y+DfFiU4XqWwoU92zt9nF5B/6+4UlzLSECsOW6QDRI7J7K4OoldvXEFUnynv8LiiOpWaVE VZ79mIuUIxVE7sLoWjLUJOwaDNdtJdjoLjbO+Dsse9GrQrvNTDxHzKWVyFPnbm7R5JWy/EIP/9 5W5XvYfmrKDhVd5JuETGYOBPWmgDRsdLligfsWQPegXt6ydG9g6h8r8RottxgqjSzmB9fDuNTd KpH9icSnUt7vGh23ij8PjFBk X-IronPort-AV: E=Sophos;i="5.85,352,1624348800"; d="scan'208";a="66826864" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 06 Oct 2021 14:04:04 -0800 IronPort-SDR: NqBYMuA7ypVSdA/fYgF3+m+tFwACyHS25+Dt/gh/kqpGJi46rpZFF5F+m/nHNH/OjXBaqWBxqM GP6tTKKIJ9FrP7axM2sPa/iNtewHaNBf6pluRwsIJ6u2ZsIQvrknynBZI/TAPoWXDA4XL8NUOW burA8lee03OW1tGN/gLC592RTfnL2yzZXrx3SzGOoF/MKiQewLYwTaQmajKwRlZtj5O5gmGxgc Gkb1N0ULdrNY7L/4y/ygbWIIS4abgk87nXIsVKLvSQFVgVORItPmuNslnlTM4GG4iLZ4d3wc5Y EaQ= Date: Wed, 6 Oct 2021 22:03:59 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Segher Boessenkool CC: Jakub Jelinek , Michael Meissner , , Thomas Koenig , , Tobias Burnus , Jonathan Wakely Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes In-Reply-To: <20211006205717.GL10333@gate.crashing.org> Message-ID: 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> <20211006205717.GL10333@gate.crashing.org> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-09.mgc.mentorg.com (139.181.222.9) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3117.8 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, 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 22:04:07 -0000 On Wed, 6 Oct 2021, Segher Boessenkool wrote: > 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). Any architecture that supports a software floating-point ABI (i.e. one that does argument passing and return for floating-point in integer registers) should specify it in its ABI documents. For example, https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc describes both "Integer Calling Convention" and "Hardware Floating-point Calling Convention", with a series of named ABIs based on those such as LP64, LP64F, etc. (like on (32-bit) Arm, but unlike Power or MIPS, RISC-V GCC also supports building programs that use hardware floating-point instructions but the software floating-point ABI). That's how the (unified) 32-bit powerpc ABI documents things: both hardware and software floating-point ABI variants. If the architecture doesn't support hardware floating point, or doesn't have separate registers for it, the software floating-point ABI is just "the ABI" and there's no separate hardware floating-point ABI, of course. -- Joseph S. Myers joseph@codesourcery.com