From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 6FA27385802D for ; Fri, 15 Oct 2021 14:21:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6FA27385802D Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-573-IqGwFzYWPpeHSS-sB_AJeA-1; Fri, 15 Oct 2021 10:20:59 -0400 X-MC-Unique: IqGwFzYWPpeHSS-sB_AJeA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 60B821923763; Fri, 15 Oct 2021 14:20:57 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.172]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F237719736; Fri, 15 Oct 2021 14:20:54 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 19FEKpiE422472 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 15 Oct 2021 16:20:51 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 19FEKnvX422167; Fri, 15 Oct 2021 16:20:49 +0200 Date: Fri, 15 Oct 2021 16:20:49 +0200 From: Jakub Jelinek To: Bill Schmidt Cc: fortran@gcc.gnu.org, gcc@gcc.gnu.org, Tobias Burnus , Segher Boessenkool , Michael Meissner , tkoenig@netcologne.de Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes Message-ID: <20211015142049.GD304296@tucnak> Reply-To: Jakub Jelinek References: <20211004100754.GL304296@tucnak> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable 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 14:21:06 -0000 On Fri, Oct 15, 2021 at 08:50:08AM -0500, Bill Schmidt wrote: > 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. > > === ... > > Is this a fair summary of the results of the discussion? For me yes. As for a separate KIND!=16 for double-double, I've looked up Fortran 2018 standard wording and it seems that the ISO C Bindings actually don't require such kind to exist, I believe C_LONG_DOUBLE should be -3 if -mabi=ibmlongdouble and we only support real KIND 4, 8 and 16 (last one IEEE quad), because it says that -3 stands for "has neither the precision nor range" and when one compiles integer function foo () foo = precision (0.0_16) end function foo integer function bar () bar = range (0.0_16) end function bar with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble 33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither precision of C long double if it is double-double nor range matches anything. If we do implement double-double support, I think KIND=15 would be better than KIND=17, it is true that double-double has for certain numbers much higher precision than IEEE quad, but the precision depends on the numbers and most of the time is smaller, the range is always smaller. And the PRECISION/RANGE intrinsic numbers are also both smaller. Jakub