Re: [PATCH] fortran, libgfortran: Avoid using libquadmath for glibc 2.26+

[Jakub Jelinek <jakub@redhat.com>]

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