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.129.124]) by sourceware.org (Postfix) with ESMTPS id 66071385022A for ; Thu, 23 Jun 2022 21:17:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 66071385022A Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-589-OU5tNqEbOFyYyBovXRa53w-1; Thu, 23 Jun 2022 17:17:55 -0400 X-MC-Unique: OU5tNqEbOFyYyBovXRa53w-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 58446802E5D; Thu, 23 Jun 2022 21:17:55 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.194.12]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 061E140CF8EE; Thu, 23 Jun 2022 21:17:54 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 25NLHpmS338479 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 23 Jun 2022 23:17:52 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 25NLHorm338477; Thu, 23 Jun 2022 23:17:50 +0200 Date: Thu, 23 Jun 2022 23:17:50 +0200 From: Jakub Jelinek To: Harald Anlauf Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, "Joseph S. Myers" Subject: Re: [PATCH] fortran, libgfortran: Avoid using libquadmath for glibc 2.26+ Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 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, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Thu, 23 Jun 2022 21:18:00 -0000 On Thu, Jun 23, 2022 at 10:49:55PM +0200, Harald Anlauf wrote: > > We need both a compiler change (so that for glibc 2.26+ it uses *f128 APIs > > instead of *q) and library change. > > this is quite an important change in the gfortran ABI, as it will > require recompilation of (library) code using quad precision. > Not that I am particularly affected, but this should be highlighted > for users. We currently use %rename lib liborig *lib: %{static-libgfortran:--as-needed} -lquadmath %{static-libgfortran:--no-as-needed} -lm %(libgcc) %(liborig) in libgfortran.spec (on targets where we do configure in libquadmath). So, I believe the patch as is is an ABI change for *.o files if they use real(kind=16) math functions (one needs to recompile them), but not for linked shared libraries or executables, because the above aranges for them to be linked with -lquadmath or for -static-libgfortran with --as-needed -lquadmath --no-as-needed. The former adds libquadmath.so.0 automatically to anything gfortran links, the latter to anything that actually needs it (i.e. has undefined math/complex *q symbols). Note, libgfortran.so.5 itself is ABI compatible, just no longer has DT_NEEDED libquadmath.so.0 and uses the *f128 APIs + str{to,from}f128 instead of *q APIs + strtoflt128 and quadmath_snprintf. Now, what we could do if we'd want to also preserve *.o file compatibility, would be for gcc configured on glibc 2.26+ change libgfortran.spec to *lib: --as-needed -lquadmath --no-as-needed -lm %(libgcc) %(liborig) so that we even without -static-libgfortran link in libquadmath.so.0 only if it is needed. So, if there will be any gcc <= 12 compiled *.o files or *.o files compiled by gcc 13 if it was configured against glibc 2.25 or older, we'd link -lquadmath in, but if there are just *.o files referencing *f128 symbols, we wouldn't. > Am I right in assuming that this also effectively fixes PR46539? > (Add -static-libquadmath). That was one of the intents of the patch. But sure, it doesn't introduce -static-libquadmath, nor arranges for -static-libgfortran to link libquadmath statically, just in some cases (gcc configured on glibc 2.26 or later) and when everything that calls real(kind=16) math functions has been recompiled arranges for libquadmath not to be used at all. > > --- gcc/fortran/trans-intrinsic.cc.jj 2022-05-16 11:14:57.587427707 +0200 > > +++ gcc/fortran/trans-intrinsic.cc 2022-06-23 11:42:03.355899271 +0200 > > @@ -155,7 +155,7 @@ builtin_decl_for_precision (enum built_i > > else if (precision == TYPE_PRECISION (double_type_node)) > > i = m->double_built_in; > > else if (precision == TYPE_PRECISION (long_double_type_node) > > - && (!gfc_real16_is_float128 > > + && ((!gfc_real16_is_float128 & !gfc_real16_is__Float128) > > Shouldn't this be && instead of & ? You're right, will fix. Jakub