From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 743D03858401; Thu, 7 Oct 2021 03:47:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 743D03858401 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1970aW1q021307; Wed, 6 Oct 2021 23:47:16 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3bh8carpcx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Oct 2021 23:47:15 -0400 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 1973S3pM009022; Wed, 6 Oct 2021 23:47:15 -0400 Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0a-001b2d01.pphosted.com with ESMTP id 3bh8carpcj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Oct 2021 23:47:15 -0400 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1973VsXj013094; Thu, 7 Oct 2021 03:42:13 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma05wdc.us.ibm.com with ESMTP id 3bef2c007y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Oct 2021 03:42:13 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1973gDJ811600620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 7 Oct 2021 03:42:13 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3DC0C112063; Thu, 7 Oct 2021 03:42:13 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E35DD112062; Thu, 7 Oct 2021 03:42:12 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.160.164.232]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTPS; Thu, 7 Oct 2021 03:42:12 +0000 (GMT) Date: Wed, 6 Oct 2021 23:42:11 -0400 From: Michael Meissner To: Segher Boessenkool Cc: Thomas Koenig , Jakub Jelinek , fortran@gcc.gnu.org, gcc@gcc.gnu.org, Tobias Burnus , Michael Meissner , Jonathan Wakely Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes Message-ID: Mail-Followup-To: Michael Meissner , Segher Boessenkool , Thomas Koenig , Jakub Jelinek , fortran@gcc.gnu.org, gcc@gcc.gnu.org, Tobias Burnus , Jonathan Wakely 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211006151744.GE10333@gate.crashing.org> X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 7GhSdIjX0-KaFrBbjA7O9xhAjZpVGR3l X-Proofpoint-ORIG-GUID: 8893ZKa-k5PvKrOFzi-I8EQJYDbPyqv0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-06_04,2021-10-06_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 suspectscore=0 lowpriorityscore=0 malwarescore=0 mlxlogscore=941 priorityscore=1501 mlxscore=0 adultscore=0 impostorscore=0 spamscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110070020 X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 03:47:19 -0000 On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote: > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote: > > On 05.10.21 23:54, Segher Boessenkool wrote: > > >>There is also the issue of binary data. If some user has written > > >>out data in double double and wants to read it in as IEEE quad, > > >>the results are going to be garbage. Another option for CONVERT > > >>might be the solution to that, or, as you wrote, having a > > >>REAL(KIND=15). It should be inaccessible via SELECTED_REAL_KIND, > > >>though. > > > > > >That means flipping the default on all PowerPC to no longer be double- > > >double. This means that you should have IEEE QP work everywhere, or the > > >people who do need more than double precision will have no recourse. > > > > I think we can exclude big-endian POWER from this - they do not have > > IEEE QP support, correct? So, exclude that from the SONAME change. > > Not correct, no. IEEE QP works fine in either endianness. > > I don't know what the libraries do, but in GCC it works just fine. It only has the support if you add the options to enable IEEE 128-bit support when compiling programs. It is off by default. > > So this would only be critical for people on little-endian POWER8 > > who use double double. Hmm... can the POWER8 handle the IEEE QP > > instructions, or would that be trap and emulate? What is the > > plan there? > > The registers used by the QP insns are the VRs. Trying to use the QP > insns on a p8 will trap. There is no kernel emulation for them afaik. > > But, for p8 there is software emulation, that GCC can generate. This > follows the ABI as for p9 and later. If the code is compiled for power8, it always uses the software functions to do the support. Buried inside of libgcc are ifunc functions that use the hardware instructions if the user is running on power9 or power10. It would be nice if any distro that changed the default used power9 as a base, instead of power8. > Converting double-double to IEEE QP should not be hard or slow? There are a lot of corner cases to get it right. IIRC, there are a few values that double double can represent that are not expressable with exact precision in IEEE 128-bit. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com