From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id E2E8E385842E; Fri, 15 Oct 2021 13:50:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E2E8E385842E Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19FCkvws007463; Fri, 15 Oct 2021 09:50:11 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3bptfjcd6q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Oct 2021 09:50:11 -0400 Received: from m0098421.ppops.net (m0098421.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 19FDhlA1014361; Fri, 15 Oct 2021 09:50:11 -0400 Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com with ESMTP id 3bptfjcd68-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Oct 2021 09:50:11 -0400 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 19FDhik5006219; Fri, 15 Oct 2021 13:50:10 GMT Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by ppma02wdc.us.ibm.com with ESMTP id 3bnm3agd9h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Oct 2021 13:50:10 +0000 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 19FDo9vb16843246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 15 Oct 2021 13:50:09 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5EFE013606A; Fri, 15 Oct 2021 13:50:09 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 131FC136069; Fri, 15 Oct 2021 13:50:08 +0000 (GMT) Received: from Bills-MacBook-Pro.local (unknown [9.211.144.136]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP; Fri, 15 Oct 2021 13:50:08 +0000 (GMT) Reply-To: wschmidt@linux.ibm.com Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes To: Jakub Jelinek , fortran@gcc.gnu.org, gcc@gcc.gnu.org Cc: Tobias Burnus , Segher Boessenkool , Michael Meissner , tkoenig@netcologne.de References: <20211004100754.GL304296@tucnak> From: Bill Schmidt Message-ID: Date: Fri, 15 Oct 2021 08:50:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211004100754.GL304296@tucnak> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 1-13qYg3QeXXGNuROFZBeGkPKfMAIqrA X-Proofpoint-GUID: MFrz-N68cMmIGswqsOnniEPhjueSrjz3 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-15_04,2021-10-14_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 clxscore=1011 spamscore=0 mlxscore=0 impostorscore=0 suspectscore=0 bulkscore=0 priorityscore=1501 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110150083 X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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: 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: Fri, 15 Oct 2021 13:50:24 -0000 Thanks, Jakub, for starting this discussion, and to everyone who weighed in. The conversation went in a number of different directions, so I'd like to summarize my understanding of points where I think there was agreement. I'd also like to separate out short-term considerations for powerpc64le and GCC 12 from other topics like supporting more targets. === First, for the short-term. For powerpc64le only (little-endian, ELFv2 ABI) Thomas suggested that Fortran's best course of action is: - Change KIND=16 in GCC 12 from double-double to IEEE QP just for affected targets - Bump the SONAME just for affected targets - Have a preprocessor flag to help #ifdef out irrelevant code (which Jakub asserted exists) - Deal with binary (unformatted) I/O with a CONVERT option for OPEN, and/or an envvar, to allow selection between the two formats There was some discussion of dual-mangling names for Fortran, but this didn't seem practical because of a number of complicating factors. There is an open question about possibly using KIND=15 or KIND=17 to represent double-double going forward. It's not clear whether or not this is necessary, but some C compatibility scenarios were cited as possible motivations. There was some concern about SONAME numbers differing across architectures, but consensus seems to be that this can be handled. Summary: I didn't see any serious pushback to Thomas's suggested course of action, and the only major open question is about maintaining a KIND to represent double-double. === Longer term, we have the question of supporting more Power targets. AIX will continue to use only double-double. It is agreed that it would be useful for 32- and 64-bit BE Linux to support IEEE QP as well, on some future timeline. The first step towards this is to develop and document ABI for IEEE QP on those targets. The simplest approach that everyone seemed to like is for these ABIs to require AltiVec support in order for IEEE QP to be supported. This allows parameters and return values to always be passed in vector registers, whether implemented with hardware instructions or a soft-float library. libquadmath can be built for these targets. [Sidebar: The ELFv1 document needs a new home, as the last version was published by the now-defunct POWER.org. But we can deal with that.] Beyond ABI and compiler support, glibc would also need to support IEEE QP for these other targets. Currently we only have support for powerpc64le. === Is this a fair summary of the results of the discussion? Thanks again! Bill