Re: [PATCH] fortran, libgfortran, v2: Avoid using libquadmath for glibc 2.26+
On Mon, 27 Jun 2022, Jakub Jelinek via Gcc-patches wrote: > On Sun, Jun 26, 2022 at 08:45:28PM +0200, Mikael Morin wrote: > > I don’t like the _Float128 vs __float128 business, it’s confusing. > > And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html > > they seem to be basically the same thing, so it’s also redundant. > > I thought __float128 and _Float128 are distinct and incompatible in the FEs > and equivalent in middle-end and back-end, but apparently they are > considered equivalent even for _Generic. Yes, when both are supported, they are the same type. The main differences (not relevant for this patch, I think) are: * _Float128 is supported on systems where long double has the IEEE binary128 format (as a distinct type from long double even when they have the same format); __float128 generally isn't supported on such systems. * __float128 is supported in C++, _Float128 isn't (though we've discussed adding support for _FloatN type names and corresponding fN constant suffixes in C++; see the thread on the gcc list in March 2021). -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] fortran, libgfortran, v2: Avoid using libquadmath for glibc 2.26+
Le 27/06/2022 à 09:54, Jakub Jelinek a écrit : Still, using __float128 when the APIs are declared for __float128 and _Float128 when the APIs are declared for _Float128 can be better for consistency. I agree with that. I was implicitly suggesting to change the libquadmath API to use the standard syntax and types, with the assumption that it’s an internal thing used only by fortran (on the frontend side and on the library side). After documenting myself further, it seems that’s a wrong assumption. If HAVE_FLOAT128 and GFC_REAL_16_IS_FLOAT128 stand for _Float128 and libquadmath or *f128 APIs, we'd need some macro to tell which APIs to use, say USE_LIBQUADMATH and USE_IEC_60559. That would be my preference, even if we keep both __float128 and _Float128, as it avoids exposing the detail of the provider of the math functions in many places it’s not needed. Half of the changes from your patch have pattern blah__float128 || blah_Float128 or the negation of that, and wouldn’t be needed if the *FLOAT128 conditions spanned both __float128 and _Float128 (or libquadmath and libc).
Re: [PATCH] fortran, libgfortran, v2: Avoid using libquadmath for glibc 2.26+
On Sun, Jun 26, 2022 at 08:45:28PM +0200, Mikael Morin wrote:
> I don’t like the _Float128 vs __float128 business, it’s confusing.
> And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
> they seem to be basically the same thing, so it’s also redundant.
I thought __float128 and _Float128 are distinct and incompatible in the FEs
and equivalent in middle-end and back-end, but apparently they are
considered equivalent even for _Generic.
Still, using __float128 when the APIs are declared for __float128 and
_Float128 when the APIs are declared for _Float128 can be better for
consistency.
But if you feel strongly that we should use _Float128 and F128/f128
suffixes on floating point constants everywhere, we'd need more work
(e.g. because we use those same suffixes also for the functions where
we need to differentiate, or on macros like M_PI etc. where it is
significant too), and we'd need to come up with new macros to differentiate
which API set to use.
In the patch I've posted,
HAVE_FLOAT128 and GFC_REAL_16_IS_FLOAT128 defines stand for
__float128 + libquadmath APIs,
HAVE__FLOAT128 and GFC_REAL_16_IS__FLOAT128 stand for
_Float128 and C *f128 APIs.
If HAVE_FLOAT128 and GFC_REAL_16_IS_FLOAT128 stand for
_Float128 and libquadmath or *f128 APIs, we'd need some macro
to tell which APIs to use, say
USE_LIBQUADMATH and USE_IEC_60559.
And the hardest part would be that we that GFC_REAL_{16,17}_LITERAL{,_SUFFIX}
is currently used everywhere while for library APIs and M_* constants
we need to differentiate. Perhaps we could just use *q suffixes even when
using _Float128 when USE_LIBQUADMATH.
Jakub
Re: [PATCH] fortran, libgfortran, v2: Avoid using libquadmath for glibc 2.26+
Hello, I don’t like the _Float128 vs __float128 business, it’s confusing. And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html they seem to be basically the same thing, so it’s also redundant. Is there a reason why the standard one, _Float128, can’t be used everywhere? Mikael
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
[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
