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 C3AF53858C60 for ; Fri, 15 Oct 2021 18:11:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C3AF53858C60 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-407-JDlxGI0GNUeqjksr-nX19A-1; Fri, 15 Oct 2021 14:11:46 -0400 X-MC-Unique: JDlxGI0GNUeqjksr-nX19A-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8529E1006AA2; Fri, 15 Oct 2021 18:11:44 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.172]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 187DB60C05; Fri, 15 Oct 2021 18:11:43 +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 19FIBeVw440394 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 15 Oct 2021 20:11:40 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 19FIBcBn440393; Fri, 15 Oct 2021 20:11:38 +0200 Date: Fri, 15 Oct 2021 20:11:38 +0200 From: Jakub Jelinek To: Thomas Koenig Cc: Bill Schmidt , fortran@gcc.gnu.org, gcc@gcc.gnu.org, Tobias Burnus , Segher Boessenkool , Michael Meissner Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes Message-ID: <20211015181138.GI304296@tucnak> Reply-To: Jakub Jelinek References: <20211004100754.GL304296@tucnak> <20211015142049.GD304296@tucnak> <4c0d1a0d-457f-68d7-94f3-420bc2c33c69@netcologne.de> MIME-Version: 1.0 In-Reply-To: <4c0d1a0d-457f-68d7-94f3-420bc2c33c69@netcologne.de> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 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=-5.5 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=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: Fri, 15 Oct 2021 18:11:52 -0000 On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote: > > 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. > > There is one potential problem: selected_real_kind. > > The standard says about that... > > # If more than one kind type parameter value meets the criteria, the > # value returned is the one with the smallest decimal precision, unless > # there are several such values, in which case the smallest of these > # kind values is returned > > So, selected_real_kind(25) would yield double double, and we would > have to violate the standard there if we wanted people to have > IEEE QP in that case. That would be true if some kind exist for double double, whether it is kind == 15 or kind == 17, no? Because precision (0.0_double_double_kind) < precision (0.0_ieee_quad_kind) so the "smallest of the kind values" doesn't trigger. Jakub