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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 8B2263858C39 for ; Thu, 7 Oct 2021 09:40:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8B2263858C39 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-478-P1o2WkWzPfOR74FLGBKA7g-1; Thu, 07 Oct 2021 05:40:27 -0400 X-MC-Unique: P1o2WkWzPfOR74FLGBKA7g-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0F26C835DE9; Thu, 7 Oct 2021 09:40:26 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.109]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 21105100238C; Thu, 7 Oct 2021 09:40:24 +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 1979eLmn3929505 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 7 Oct 2021 11:40:21 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 1979eJoJ3929504; Thu, 7 Oct 2021 11:40:19 +0200 Date: Thu, 7 Oct 2021 11:40:18 +0200 From: Jakub Jelinek To: Thomas Koenig Cc: Michael Meissner , fortran@gcc.gnu.org, gcc@gcc.gnu.org, Tobias Burnus , Segher Boessenkool , David Edelsohn Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes Message-ID: <20211007094018.GR304296@tucnak> Reply-To: Jakub Jelinek References: <20211004100754.GL304296@tucnak> <3dacfdf6-6b23-f307-969a-94265b506edb@netcologne.de> MIME-Version: 1.0 In-Reply-To: <3dacfdf6-6b23-f307-969a-94265b506edb@netcologne.de> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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: 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: Thu, 07 Oct 2021 09:40:33 -0000 On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote: > On 07.10.21 05:35, Michael Meissner via Fortran wrote: > > I tried this at one point. There are a lot of hidden assumptions that the kind > > number is the number of bytes. I'm sure it can be tracked down, but the > > problem is with these assumptions is you can't prove a negative (i.e. you never > > know that you've missed some). > > So, summing up from the Fortran side, I'd say the best course of action > is to > > - make KIND=16 into IEEE QP > > - bump the SONAME on on affected systems on POWER and nowhere else > > - have a preprocessor flag so we can #ifdef out code which is relevant > only there If for libgfortran purposes, we already have one. > - provide a CONVERT option (have to think of a suitable syntax) to > do unformatted I/O either in IEEE QP or double double, but only > on affected systems, so people can set this either via a CONVERT > option on open or an environment variable. For OPEN, we should > extend the existing one, for an environment variable, I'd say > we should use a new one and reuse the existing parsing routines. So no extra KIND=15 support for double double? The above essentially means unlike the C/C++ world where the decision on what is long double we defer to distributions "when they are ready" (at gcc configure time for the default, or to users through -mabi=ieeelongdouble or -mabi=ibmlongdouble) for the Fortran we'd make the decision on the GCC side (in GCC 11 and earlier real(kind=16) is double double, in GCC 12+ on ppc64le real(kind=16) is IEEE QP), regardless of the -mabi=*longdouble flags etc. As Joseph mentioned, on the Fortran side doing that is easier than on the C/C++ side, where there is e.g. the requirement for GLIBC 2.32 or later for IEEE QP, for Fortran we'll need to decide at gcc configure time and either build libquadmath for ppc64le too (if glibc is older than 2.32) or use the libm stuff instead. Oh, and I guess some small difficulties will there be in the C compatibility, e.g. what to do iso_c_binding c_long_double and c_long_double_complex, if C and Fortran agree (depending on gcc configure time decision and -mabi=*longdouble) then it would be 16, but it is unclear what can be done for the case where the C long double doesn't have a corresponding Fortran kind... So maybe KIND=15 support would be useful at least for that. Jakub