From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout3.netcologne.de (cc-smtpout3.netcologne.de [IPv6:2001:4dd0:100:1062:25:2:0:3]) by sourceware.org (Postfix) with ESMTPS id 1CD393858415; Wed, 6 Oct 2021 07:00:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1CD393858415 Received: from cc-smtpin2.netcologne.de (cc-smtpin2.netcologne.de [89.1.8.202]) by cc-smtpout3.netcologne.de (Postfix) with ESMTP id 4C01F125A0; Wed, 6 Oct 2021 09:00:01 +0200 (CEST) Received: from [IPv6:2001:4dd7:2fa2:0:7285:c2ff:fe6c:992d] (2001-4dd7-2fa2-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de [IPv6:2001:4dd7:2fa2:0:7285:c2ff:fe6c:992d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin2.netcologne.de (Postfix) with ESMTPSA id 9626E11DBB; Wed, 6 Oct 2021 08:59:53 +0200 (CEST) Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes To: Segher Boessenkool Cc: Jakub Jelinek , fortran@gcc.gnu.org, gcc@gcc.gnu.org, Tobias Burnus , Michael Meissner , Jonathan Wakely References: <20211004100754.GL304296@tucnak> <20211004141410.GP304296@tucnak> <6d845542-536e-1a0f-70e9-d05eea98aae7@netcologne.de> <20211005215450.GC10333@gate.crashing.org> From: Thomas Koenig Message-ID: <90df1250-9b3f-4a55-bc67-e3e05e54f7ef@netcologne.de> Date: Wed, 6 Oct 2021 08:59:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20211005215450.GC10333@gate.crashing.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-NetCologne-Spam: L X-Rspamd-Queue-Id: 9626E11DBB X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, 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: Wed, 06 Oct 2021 07:00:07 -0000 On 05.10.21 23:54, Segher Boessenkool wrote: > Hi! > > On Tue, Oct 05, 2021 at 10:16:47PM +0200, Thomas Koenig wrote: >> On 04.10.21 16:14, Jakub Jelinek via Fortran wrote: >>> Based on some IRC discussion, yet another option would be bump libgfortran >>> SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean >>> always IEEE quad (starting with GCC 12) and if wanted add support for >>> real(kind=15) meaning double double. >> >> Bumping the SONAME for everybody even on architectures which are >> not affected (like x86 or ARM) does not really feel right. We will >> probably have to do it sooner or later, at least to get PDTs right >> (and for array descriptor reform), but we will then have to >> do another SONAME change when we do that (it is certainly not >> ready now). > > You do not have to change soname more than once per release. > > You could leave it at the old value for archs not affected. It is good > for everyone's sanity to keep the same numbers for all archs though, so, > just skip some for some archs. That's the best way, I think - no disruption on all other systems. > Everyone who uses -static won't be hurt either way. > >> 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. 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? > It will be great if you can do this at the same time, get all the pain > over with at the same time, have better results for everyone. Heck, you > only need the "kind=15" for compatibility then. It would still mean that people would have to change their source code, especially those who have followed the standard convention of using selected_real_kind. Not sure what the consequences would be. > People who have data stored in the old format will be in a tough spot > no matter what. Presumably everyone will want to convert to the > standard format at some point. In that case, extending the CONVERT option to the OPEN statement might be the best way (plus the corresponding handling of the environment variables and options). It would be slow, especially when honoring NaN and INF, but people could at least read in data and then write it out again. Best regards Thomas