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 8E4A93858406; Wed, 6 Oct 2021 17:14:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8E4A93858406 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: erPWfGlK9Yvi23HsXHldqt7gwJ2uGC4+lE8ekQ4+T684nTGq1dumrHAgu7RiZjezBa8tK7ephJ 0Gz9rv3w9DYcQys6w/HiFtx7AJ98QoWBjo5DJnxcosYzjnY8YOaHJEWgq7ZYx5+Ln6ljXl9zB8 noyv5Tueen8odMtfEXmFGdsw1rei4hSOm+aceaZabijDZscBOPdB0ezdpzfEupZiSEcY3tFK+Q /V1/lK0tQF2rzKb/Zd/xvqAre0rsFVSil2MrWZpXY7KWtjlrx6qj5kZRKKyESONm/vokTOdo9G CT4qr8NXeizoiDPuVjjgq3IS X-IronPort-AV: E=Sophos;i="5.85,352,1624348800"; d="scan'208";a="66805653" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 06 Oct 2021 09:14:04 -0800 IronPort-SDR: 00eMriwpQYwHkhaYLwFJ/0in/d+PBaRbF5kid+urAHGCJhfQPgQgsKZDNanfiH7pdx2VfkBEsK paey0FCIdWuS3K7SWpTI7OEIcTj0DL+6Lq8xxKdP05MeJbIHUevJQwboCeueV2iuPM5BRze9fo JmaFAsf+4b7Nv1pI621rN/D+910Hym1FB3FzbYXpVdLmDMyd5WsKWhXBkztDXKbK38/Ej5dRJy lJZGbZUdFapbjpVItsgsFr/cavpn2mOZTuOUl89+hw6g/d/sFXHl0+ivBQddFSz49myLVC4fnC pF4= Date: Wed, 6 Oct 2021 17:13:59 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Jakub Jelinek CC: Segher Boessenkool , Michael Meissner , , Thomas Koenig , , Tobias Burnus , Jonathan Wakely Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes In-Reply-To: <20211006163433.GM304296@tucnak> Message-ID: 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> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-05.mgc.mentorg.com (139.181.222.5) 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 17:14:08 -0000 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. > 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). And, then, decide the 32-bit ABIs (hard and soft float), if you want to support _Float128 there. 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. -- Joseph S. Myers joseph@codesourcery.com