[PATCH] fortran, libgfortran, v2: Avoid using libquadmath for glibc 2.26+
On Thu, Jun 23, 2022 at 11:17:50PM +0200, Jakub Jelinek via Gcc-patches wrote:
> 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.
Here is an updated patch that does that.
> > > --- gcc/fortran/trans-intrinsic.cc.jj 2022-05-16 11:14:57.587427707
> > > +0200
> > > +++ gcc/fortran/trans-intrinsic.cc2022-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.
And this too.
So I believe it should now be fully ABI compatible.
2022-06-24 Jakub Jelinek
gcc/fortran/
* gfortran.h (gfc_real_inf0: Add c__Float128 bitfield.
* trans-types.h (gfc_real16_is_float128): Update comment.
(gfc_real16_is__Float128): Declare.
* trans-types.cc (gfc_real16_is__Float128): Define.
(gfc_init_kinds): When building powerpc64le-linux libgfortran
on glibc 2.26 to 2.31, set gfc_real16_is__Float128 and
c__Float128 instead of gfc_real16_is_float128 and c_float128.
(gfc_build_real_type): Don't set c_long_double if c__Float128.
Set gfc_real16_is__Float128 and c__Float128 instead of
gfc_real16_is_float128 and c_float128 on glibc 2.26 or later.
(gfc_init_types): Handle c__Float128 like c_float128.
* trans-intrinsic.cc (builtin_decl_for_precision): Handle
gfc_real16_is__Float128 like gfc_real16_is_float128.
(gfc_builtin_decl_for_float_kind): Handle c__Float128 like c_float128.
(gfc_build_intrinsic_lib_fndecls): For gfc_real16_is__Float128
use *f128 APIs rather than *q APIs used for gfc_real16_is_float128.
(gfc_get_intrinsic_lib_fndecl): Likewise.
* trans-expr.cc (gfc_conv_power_op): Handle gfc_real16_is__Float128
like gfc_real16_is_float128.
libgfortran/
* configure.ac: Check for strtof128 and strfromf128.
Check for math and complex *f128 functions. Set
have__Float128_libc_support to yes if *f128 support is around, for
--enable-libquadmath-support default to "default" rather than yes if
have__Float128_libc_support is yes.
* acinclude.m4 (LIBGFOR_CHECK_FLOAT128): If libquadmath support
is defaulted and have__Float128_libc_support is yes, test
_Float128/_Complex _Float128 support and define and subst
HAVE__FLOAT128. Remove unused LIBGFOR_BUILD_QUAD conditional.
* Makefile.am (kinds.h): Pass @HAVE__FLOAT128@ as an extra
mk-kinds-h.sh argument.
* mk-kinds-h.sh: Accept 4th have__float128 argument, if it is yes,
use _Float128/_Complex _Float128 types insted of __float128 and
_Complex float __attribute__((mode(TC))), use f128 suffix instead
of q and define GFC_REAL_16_IS__FLOAT128 instead o
Re: [PATCH 6/8] fortran: use grep -F instead of fgrep
On Fri, 24 Jun 2022 15:06:32 +0800 Xi Ruoyao via Gcc-patches wrote: > fgrep has been deprecated in favor of grep -F for a long time, and the > next grep release (3.8 or 4.0) will print a warning of fgrep is used. > Stop using fgrep so we won't see the warning. > > gcc/ChangeLog: > > * fortran/Make-lang.in: Use grep -F instead of fgrep. > --- > gcc/fortran/Make-lang.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/fortran/Make-lang.in b/gcc/fortran/Make-lang.in > index 1cb47cb1a52..51279b03aad 100644 > --- a/gcc/fortran/Make-lang.in > +++ b/gcc/fortran/Make-lang.in > @@ -278,7 +278,7 @@ $(DESTDIR)$(man1dir)/$(GFORTRAN_INSTALL_NAME)$(man1ext): > doc/gfortran.1 \ > -chmod a-x $@ > > fortran.uninstall: > - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i > debian' >/dev/null 2>&1; then \ > + if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i > debian' >/dev/null 2>&1; then \ > echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) > $(DESTDIR)$(infodir)/gfortran.info"; \ > install-info --delete --info-dir=$(DESTDIR)$(infodir) > $(DESTDIR)$(infodir)/gfortran.info || : ; \ > else : ; fi; \ I'd replace -s >/dev/null 2>&1 with -q while at it. But why is -F used here in the first place? I do not see much in debian that can be interpreted as a regex? thanks,
Re: [PATCH 6/8] fortran: use grep -F instead of fgrep
On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote: > > - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i > > debian' >/dev/null 2>&1; then \ > > + if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i > > debian' >/dev/null 2>&1; then \ > > echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) > > $(DESTDIR)$(infodir)/gfortran.info"; \ > > install-info --delete --info-dir=$(DESTDIR)$(infodir) > > $(DESTDIR)$(infodir)/gfortran.info || : ; \ > > else : ; fi; \ > > I'd replace -s >/dev/null 2>&1 with -q while at it. > > But why is -F used here in the first place? > I do not see much in debian that can be interpreted as a regex? I'm not sure. It was there since 2004. Perhaps the author thinks fgrep may save several CPU cycles :). I'll just use a plain grep in PATCH v2. Rainer: do you have some idea about the availability of "-q" on different hosts? If you agree I'll use it instead of -s > /dev/null too. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH 6/8] fortran: use grep -F instead of fgrep
Hi Xi, > On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote: > >> > - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v >> > -i debian' >/dev/null 2>&1; then \ >> > + if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v >> > -i debian' >/dev/null 2>&1; then \ >> > echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) >> > $(DESTDIR)$(infodir)/gfortran.info"; \ >> > install-info --delete --info-dir=$(DESTDIR)$(infodir) >> > $(DESTDIR)$(infodir)/gfortran.info || : ; \ >> > else : ; fi; \ >> >> I'd replace -s >/dev/null 2>&1 with -q while at it. >> >> But why is -F used here in the first place? >> I do not see much in debian that can be interpreted as a regex? > > I'm not sure. It was there since 2004. Perhaps the author thinks fgrep > may save several CPU cycles :). I'll just use a plain grep in PATCH v2. > > Rainer: do you have some idea about the availability of "-q" on > different hosts? If you agree I'll use it instead of -s > /dev/null > too. again, the autoconf manual warns agains it, even more so against -s. That's the first reference for portability issues and shouldn't be ignored without good reason. In the GCC and Solaris context, /bin/grep supports both -q and -s in Solaris 11.3 and 11.4. It doesn't support -q on Solaris 10, though (again, no longer relevant for GCC). Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH 6/8] fortran: use grep -F instead of fgrep
Hi, On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote: - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' >/dev/null 2>&1; then \ + if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i debian' >/dev/null 2>&1; then \ echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/gfortran.info"; \ install-info --delete --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/gfortran.info || : ; \ else : ; fi; \ I'd replace -s >/dev/null 2>&1 with -q while at it. But why is -F used here in the first place? I do not see much in debian that can be interpreted as a regex? I'm not sure. It was there since 2004. Perhaps the author thinks fgrep may save several CPU cycles :). I'll just use a plain grep in PATCH v2. Rainer: do you have some idea about the availability of "-q" on different hosts? If you agree I'll use it instead of -s > /dev/null too. Is there any particular reason why we should not use the result of AC_PROG_FGREP ? AC_PROG_GREP should also work.
[PATCH] libgfortran: Avoid using libquadmath powerpc64le fixes
Hi! Testing this on powerpc64le-linux revealed some problems with the patch when gcc is configured against glibc 2.26 through 2.31. Here is incremental patch (against the v2 patch) that fixes it. Built and tested on powerpc64le-linux with glibc 2.28, ok for trunk? 2022-06-24 Jakub Jelinek * kinds-override.h (GFC_REAL_17, GFC_COMPLEX_17, GFC_REAL_17_HUGE, GFC_REAL_17_LITERAL_SUFFIX,GFC_REAL_17_LITERAL): Define differently if HAVE__FLOAT128 is defined. * intrinsics/erfc_scaled.c (_THRESH, _M_2_SQRTPI, _ERFC, _EXP): Likewise. * m4/mtype.m4: Use f128 suffix for GFC_REAL_17 if not POWER_IEEE128 and HAVE__FLOAT128 is defined. * io/read.c (convert_real): Handle HAVE__FLOAT128 differently if POWER_IEEE128 is not defined. * io/transfer128.c (tmp1, tmp2): Likewise. * io/write_float.def (gfor_strfromf128): Define even for GFC_REAL_17 if POWERPC_IEEE128 isn't defined and HAVE__FLOAT128 is. (DTOA2Q, FDTOA2Q): Define differently for GFC_REAL_17 if POWERPC_IEEE128 isn't defined and HAVE__FLOAT128 is. * generated/norm2_r17.c: Regenerated. * generated/bessel_r17.c: Regenerated. --- libgfortran/kinds-override.h.jj 2022-06-22 12:40:05.170224299 +0200 +++ libgfortran/kinds-override.h2022-06-24 14:19:00.886823630 +0200 @@ -34,13 +34,24 @@ see the files COPYING3 and COPYING.RUNTI /* Keep these conditions on one line so grep can filter it out. */ #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16 +#ifdef HAVE__FLOAT128 +typedef _Float128 GFC_REAL_17; +typedef _Complex _Float128 GFC_COMPLEX_17; +#else typedef __float128 GFC_REAL_17; typedef _Complex float __attribute__((mode(KC))) GFC_COMPLEX_17; +#endif #define HAVE_GFC_REAL_17 #define HAVE_GFC_COMPLEX_17 +#ifdef HAVE__FLOAT128 +#define GFC_REAL_17_HUGE 1.18973149535723176508575932662800702e4932f128 +#define GFC_REAL_17_LITERAL_SUFFIX f128 +#define GFC_REAL_17_LITERAL(X) (X ## f128) +#else #define GFC_REAL_17_HUGE 1.18973149535723176508575932662800702e4932q #define GFC_REAL_17_LITERAL_SUFFIX q #define GFC_REAL_17_LITERAL(X) (X ## q) +#endif #define GFC_REAL_17_DIGITS 113 #define GFC_REAL_17_RADIX 2 #endif --- libgfortran/intrinsics/erfc_scaled.c.jj 2022-06-24 07:38:55.640826314 -0400 +++ libgfortran/intrinsics/erfc_scaled.c2022-06-24 09:10:05.311263353 -0400 @@ -147,12 +147,15 @@ ERFC_SCALED(16) /* For quadruple-precision, netlib's implementation is not accurate enough. We provide another one. */ -# define _THRESH -106.566990228185312813205074546585730Q -# define _M_2_SQRTPI M_2_SQRTPIq +# define _THRESH GFC_REAL_17_LITERAL(-106.566990228185312813205074546585730) +# define _M_2_SQRTPI GFC_REAL_17_LITERAL(M_2_SQRTPI) # define _INF __builtin_inff128() # ifdef POWER_IEEE128 # define _ERFC(x) __erfcieee128(x) # define _EXP(x) __expieee128(x) +# elif defined(HAVE__FLOAT128) +# define _ERFC(x) erfcf128(x) +# define _EXP(x) expf128(x) # else # define _ERFC(x) erfcq(x) # define _EXP(x) expq(x) --- libgfortran/m4/mtype.m4.jj 2022-06-22 13:52:56.987824469 +0200 +++ libgfortran/m4/mtype.m4 2022-06-24 14:21:40.435769659 +0200 @@ -15,6 +15,8 @@ ifelse(kind,17,`1 /* FIXME: figure this define(mathfunc_macro,`ifelse(kind,17,dnl `#if defined(POWER_IEEE128) #define MATHFUNC(funcname) __ ## funcname ## ieee128 +#elif defined(HAVE__FLOAT128) +#define MATHFUNC(funcname) funcname ## f128 #else #define MATHFUNC(funcname) funcname ## q #endif',dnl --- libgfortran/io/read.c.jj2022-06-22 14:13:35.351567588 +0200 +++ libgfortran/io/read.c 2022-06-24 14:29:43.19939 +0200 @@ -203,6 +203,8 @@ convert_real (st_parameter_dt *dtp, void case 17: # if defined(POWER_IEEE128) *((GFC_REAL_17*) dest) = __strtoieee128 (buffer, &endptr); +# elif defined(HAVE__FLOAT128) + *((GFC_REAL_17*) dest) = strtof128 (buffer, &endptr); # else *((GFC_REAL_17*) dest) = __qmath_(strtoflt128) (buffer, &endptr); # endif --- libgfortran/io/transfer128.c.jj 2022-06-22 13:20:31.657252114 +0200 +++ libgfortran/io/transfer128.c2022-06-24 14:31:18.616329211 +0200 @@ -67,7 +67,8 @@ export_proto(transfer_complex128_write); that there is a non-weakref dependence if the quadmath functions are used. That avoids segfault when libquadmath is statically linked. */ # ifndef GFC_REAL_16_IS__FLOAT128 -# if !defined(HAVE_GFC_REAL_17) || !defined(POWER_IEEE128) +# if !defined(HAVE_GFC_REAL_17) \ + || (!defined(POWER_IEEE128) && !defined(HAVE__FLOAT128)) static void __attribute__((used)) *tmp1 = strtoflt128; static void __attribute__((used)) *tmp2 = quadmath_snprintf; # endif --- libgfortran/io/write_float.def.jj 2022-06-24 07:38:55.640826314 -0400 +++ libgfortran/io/write_float.def 2022-06-24 09:13:48.653519940 -0400 @@ -837,7 +837,9 @@ snprintf (buffer, size, "%+-#.*e", (prec #define DTOA2L(prec,val) \ snprint
Re: [PATCH 6/8] fortran: use grep -F instead of fgrep
On 24 June 2022 14:35:20 CEST, Rainer Orth wrote: >Hi Xi, > >> On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote: >> >>> > - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v >>> > -i debian' >/dev/null 2>&1; then \ >>> > + if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v >>> > -i debian' >/dev/null 2>&1; then \ >>> > echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) >>> > $(DESTDIR)$(infodir)/gfortran.info"; \ >>> > install-info --delete --info-dir=$(DESTDIR)$(infodir) >>> > $(DESTDIR)$(infodir)/gfortran.info || : ; \ >>> > else : ; fi; \ >>> >>> I'd replace -s >/dev/null 2>&1 with -q while at it. >>> >>> But why is -F used here in the first place? >>> I do not see much in debian that can be interpreted as a regex? >> >> I'm not sure. It was there since 2004. Perhaps the author thinks fgrep >> may save several CPU cycles :). I'll just use a plain grep in PATCH v2. >> >> Rainer: do you have some idea about the availability of "-q" on >> different hosts? If you agree I'll use it instead of -s > /dev/null >> too. > >again, the autoconf manual warns agains it, even more so against -s. >That's the first reference for portability issues and shouldn't be >ignored without good reason. > >In the GCC and Solaris context, /bin/grep supports both -q and -s in >Solaris 11.3 and 11.4. It doesn't support -q on Solaris 10, though >(again, no longer relevant for GCC). The good reason I would bring forward is that the systems mentioned in the autoconf docs are all not supported anymore (IRIX, ancient or old Solaris etc). Furthermore, grep(1) is required by POSIX to support -q since at least 1997; see https://pubs.opengroup.org/onlinepubs/007908799/xcu/grep.html That's about 25 years now, so everybody had plenty of time to implement this specific part, which is even trivial to implement for this particular case of grep -q. All in all i think that we should not be held hostage by such systems any longer, at least for such cases that are trivial to fix to conformance. Of course that may be just /me. Iff fixing egrep or fgrep occurrences though, we should use plain grep where applicable, like in this case, IMO. thanks,
[PATCH, committed] Fortran: fix checking of arguments to UNPACK when MASK is a variable [PR105813]
Dear all,
we failed to fully check arguments to UNPACK when the MASK
argument was not simplified and considered a variable instead
of an array. The fix is a one-liner.
Regtested on x86_64-pc-linux-gnu and committed to mainline
as obvious after an OK by Steve in the PR.
Thanks,
Harald
From f21f17f95c0237f4f987a5fa9f1fa9c7e0db3c40 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 24 Jun 2022 22:21:39 +0200
Subject: [PATCH] Fortran: fix checking of arguments to UNPACK when MASK is a
variable [PR105813]
gcc/fortran/ChangeLog:
PR fortran/105813
* check.cc (gfc_check_unpack): Try to simplify MASK argument to
UNPACK so that checking of the VECTOR argument can work when MASK
is a variable.
gcc/testsuite/ChangeLog:
PR fortran/105813
* gfortran.dg/unpack_vector_1.f90: New test.
---
gcc/fortran/check.cc | 2 ++
gcc/testsuite/gfortran.dg/unpack_vector_1.f90 | 12
2 files changed, 14 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/unpack_vector_1.f90
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 0c2cb50c6a7..91d87a1b2c1 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6353,6 +6353,8 @@ gfc_check_unpack (gfc_expr *vector, gfc_expr *mask, gfc_expr *field)
if (!same_type_check (vector, 0, field, 2))
return false;
+ gfc_simplify_expr (mask, 0);
+
if (mask->expr_type == EXPR_ARRAY
&& gfc_array_size (vector, &vector_size))
{
diff --git a/gcc/testsuite/gfortran.dg/unpack_vector_1.f90 b/gcc/testsuite/gfortran.dg/unpack_vector_1.f90
new file mode 100644
index 000..5347c111e8f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/unpack_vector_1.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR fortran/105813
+! Fix checking of VECTOR argument to UNPACK when MASK is a variable.
+! Contributed by G.Steinmetz
+
+program p
+ logical, parameter :: mask(2,2) = reshape ([.true., .true., &
+ .false., .true.], &
+ shape (mask))
+ print *, unpack ([1,2,3], mask, 0) ! OK
+ print *, unpack ([1,2], mask, 0) ! { dg-error "must provide at least" }
+end
--
2.35.3
Re: [PATCH] fortran, libgfortran, v2: Avoid using libquadmath for glibc 2.26+
Hi Jakub,
Am 24.06.22 um 12:29 schrieb Jakub Jelinek via Gcc-patches:
On Thu, Jun 23, 2022 at 11:17:50PM +0200, Jakub Jelinek via Gcc-patches wrote:
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.
Here is an updated patch that does that.
very good!
--- 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.
And this too.
So I believe it should now be fully ABI compatible.
Great, thanks!
Harald
