Re: [power-ieee128] RFH: LTO broken
On Tue, Jan 04, 2022 at 12:07:49PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 03, 2022 at 11:43:57PM +0100, Thomas Koenig wrote:
> > > clearly there is still work to fix (but seems e.g. most of the lto tests
> > > are related to the gnu attributes stuff:( ).
> >
> > This is looking better than what I expected. Apart from LTO, I expect
>
> I've just verified that LTO is broken even in C/C++, it isn't just gfortran.
> Just do
> make check-gcc RUNTESTFLAGS='--target_board=unix\{-mabi=ieeelongdouble\}
> lto.exp'
> on a system where gcc is configured to default to -mabi=ibmlongdouble
> with glibc 2.32 or later and watch all the FAILs.
> All the failures look like:
> /home/jakub/gcc/obj/gcc/xgcc -B/home/jakub/gcc/obj/gcc/ c_lto_20081024_0.o
> -mabi=ieeelongdouble -fdiagnostics-plain-output -O0 -flto
> -flto-partition=none -o gcc-
> dg-lto-20081024-01.exe
> lto1: warning: Using IEEE extended precision 'long double' [-Wpsabi]
> FAIL: gcc.dg/lto/20081024 c_lto_20081024_0.o-c_lto_20081024_0.o link, -O0
> -flto -flto-partition=none
>
> Michael, do you think you could have a look? Either it is the ELF object
> created for debug info or the one created by lto1.
>
> Jakub
>
The problem is in rs6000_option_override_internal. I allowed C and C++ to
change the long double format, but not other languages. I forgot that LTO is
another front end. I have a patch to remove the checks for C/C++.
I hope to validate it and send it out before the end of the night for me.
Note, I have a day surgery tomorrow, and I will be offline for at least part of
the day.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Re: [power-ieee128] RFH: LTO broken
On Tue, Jan 04, 2022 at 12:07:49PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 03, 2022 at 11:43:57PM +0100, Thomas Koenig wrote:
> > > clearly there is still work to fix (but seems e.g. most of the lto tests
> > > are related to the gnu attributes stuff:( ).
> >
> > This is looking better than what I expected. Apart from LTO, I expect
>
> I've just verified that LTO is broken even in C/C++, it isn't just gfortran.
> Just do
> make check-gcc RUNTESTFLAGS='--target_board=unix\{-mabi=ieeelongdouble\}
> lto.exp'
> on a system where gcc is configured to default to -mabi=ibmlongdouble
> with glibc 2.32 or later and watch all the FAILs.
> All the failures look like:
> /home/jakub/gcc/obj/gcc/xgcc -B/home/jakub/gcc/obj/gcc/ c_lto_20081024_0.o
> -mabi=ieeelongdouble -fdiagnostics-plain-output -O0 -flto
> -flto-partition=none -o gcc-
> dg-lto-20081024-01.exe
> lto1: warning: Using IEEE extended precision 'long double' [-Wpsabi]
> FAIL: gcc.dg/lto/20081024 c_lto_20081024_0.o-c_lto_20081024_0.o link, -O0
> -flto -flto-partition=none
>
> Michael, do you think you could have a look? Either it is the ELF object
> created for debug info or the one created by lto1.
Here is the patch:
| From 22b778e6ea951774df921a2a49c0cf75a2b512a3 Mon Sep 17 00:00:00 2001
| From: Michael Meissner
| Date: Wed, 5 Jan 2022 22:23:19 -0500
| Subject: [PATCH] Allow other languages to change long double format.
With Fortran adding support for changing the long double format, this
patch removes the code that only allowed C/C++ to change the long double
format for GLIBC 2.32 and later without a warning.
gcc/
2022-01-05 Michael Meissner
* config/rs6000/rs6000.c (rs6000_option_override_internal): Remove
checks for only C/C++ front ends before allowing the long double
format to change without a warning.
---
gcc/config/rs6000/rs6000.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 319182e94d9..0e3481c8327 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -4221,13 +4221,11 @@ rs6000_option_override_internal (bool global_init_p)
if (rs6000_ieeequad != TARGET_IEEEQUAD_DEFAULT && TARGET_LONG_DOUBLE_128)
{
/* Determine if the user can change the default long double type at
-compilation time. Only C and C++ support this, and you need GLIBC
-2.32 or newer. Only issue one warning. */
+compilation time. You need GLIBC 2.32 or newer to be able to
+change the long double type. Only issue one warning. */
static bool warned_change_long_double;
- if (!warned_change_long_double
- && (!glibc_supports_ieee_128bit ()
- || (!lang_GNU_C () && !lang_GNU_CXX (
+ if (!warned_change_long_double && !glibc_supports_ieee_128bit ())
{
warned_change_long_double = true;
if (TARGET_IEEEQUAD)
--
2.33.1
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Re: [power-ieee128] RFH: LTO broken
On Tue, Jan 04, 2022 at 12:07:49PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 03, 2022 at 11:43:57PM +0100, Thomas Koenig wrote:
> > > clearly there is still work to fix (but seems e.g. most of the lto tests
> > > are related to the gnu attributes stuff:( ).
> >
> > This is looking better than what I expected. Apart from LTO, I expect
>
> I've just verified that LTO is broken even in C/C++, it isn't just gfortran.
> Just do
> make check-gcc RUNTESTFLAGS='--target_board=unix\{-mabi=ieeelongdouble\}
> lto.exp'
> on a system where gcc is configured to default to -mabi=ibmlongdouble
> with glibc 2.32 or later and watch all the FAILs.
> All the failures look like:
> /home/jakub/gcc/obj/gcc/xgcc -B/home/jakub/gcc/obj/gcc/ c_lto_20081024_0.o
> -mabi=ieeelongdouble -fdiagnostics-plain-output -O0 -flto
> -flto-partition=none -o gcc-
> dg-lto-20081024-01.exe
> lto1: warning: Using IEEE extended precision 'long double' [-Wpsabi]
> FAIL: gcc.dg/lto/20081024 c_lto_20081024_0.o-c_lto_20081024_0.o link, -O0
> -flto -flto-partition=none
>
> Michael, do you think you could have a look? Either it is the ELF object
> created for debug info or the one created by lto1.
I pushed the patch to the branch.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Re: [power-ieee128] RFH: LTO broken
On 06.01.22 06:00, Michael Meissner via Fortran wrote: I pushed the patch to the branch. Test results are looking quite good right now. What is still missing is the conversion for unformatted I/O, both ways. I'll start doing some stuff on it. Just one question: What are functions that I can use to convert from IBM long double to IEEE and long double and vice versa? It was in an e-mail somewhere, but I cannot find it at the moment. Best regards Thomas
Re: [power-ieee128] RFH: LTO broken
On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote:
> On 06.01.22 06:00, Michael Meissner via Fortran wrote:
> > I pushed the patch to the branch.
>
> Test results are looking quite good right now.
>
> What is still missing is the conversion for unformatted I/O, both
> ways. I'll start doing some stuff on it. Just one question:
> What are functions that I can use to convert from IBM long double
> to IEEE and long double and vice versa? It was in an e-mail somewhere,
> but I cannot find it at the moment.
Under the hood __extendkftf2 and __trunctfkf2, as can be seen on:
__ibm128 foo (__float128 x) { return x; }
__float128 bar (__ibm128 x) { return x; }
But, I really don't think libgfortran should call those by hand, just
use C casts, (GFC_REAL_17) var_with_GFC_REAL_16_type or
(GFC_REAL_16) var_with_GFC_REAL_17_type.
Jakub
Re: [power-ieee128] RFH: LTO broken
On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote: > > On 06.01.22 06:00, Michael Meissner via Fortran wrote: > > I pushed the patch to the branch. > > Test results are looking quite good right now. I've just tried to build libgfortran on an old glibc system (gcc112.fsffrance.org) and unfortunately we still have work to do: [jakub@gcc2-power8 obj38]$ LD_PRELOAD=/home/jakub/gcc/obj38/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5.0.0 /bin/true [jakub@gcc2-power8 obj38]$ LD_BIND_NOW=1 LD_PRELOAD=/home/jakub/gcc/obj38/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5.0.0 /bin/true /bin/true: symbol lookup error: /home/jakub/gcc/obj38/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5.0.0: undefined symbol: __atan2ieee128 While we do use some libquadmath APIs: readelf -Wr /home/jakub/gcc/obj38/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5.0.0 | grep QUADMATH 00251268 05e40026 R_PPC64_ADDR64 quadmath_snprintf@QUADMATH_1.0 + 0 00251270 03060026 R_PPC64_ADDR64 strtoflt128@QUADMATH_1.0 + 0 002502e0 01160015 R_PPC64_JMP_SLOT ynq@QUADMATH_1.0 + 0 00250390 01600015 R_PPC64_JMP_SLOT sqrtq@QUADMATH_1.0 + 0 00250508 01fa0015 R_PPC64_JMP_SLOT fmaq@QUADMATH_1.0 + 0 00250530 02120015 R_PPC64_JMP_SLOT fabsq@QUADMATH_1.0 + 0 00250760 03060015 R_PPC64_JMP_SLOT strtoflt128@QUADMATH_1.0 + 0 00250990 03df0015 R_PPC64_JMP_SLOT cosq@QUADMATH_1.0 + 0 002509f0 040a0015 R_PPC64_JMP_SLOT expq@QUADMATH_1.0 + 0 00250a88 04510015 R_PPC64_JMP_SLOT erfcq@QUADMATH_1.0 + 0 00250a98 045e0015 R_PPC64_JMP_SLOT jnq@QUADMATH_1.0 + 0 00250ac8 047e0015 R_PPC64_JMP_SLOT sinq@QUADMATH_1.0 + 0 00250e38 05db0015 R_PPC64_JMP_SLOT fmodq@QUADMATH_1.0 + 0 00250e48 05e00015 R_PPC64_JMP_SLOT tanq@QUADMATH_1.0 + 0 00250e58 05e40015 R_PPC64_JMP_SLOT quadmath_snprintf@QUADMATH_1.0 + 0 00250f20 06290015 R_PPC64_JMP_SLOT copysignq@QUADMATH_1.0 + 0 we don't do it consistently: readelf -Wr /home/jakub/gcc/obj38/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5.0.0 | grep ieee128 00250310 01280015 R_PPC64_JMP_SLOT __atan2ieee128 + 0 00250340 01420015 R_PPC64_JMP_SLOT __clogieee128 + 0 00250438 01a30015 R_PPC64_JMP_SLOT __acoshieee128 + 0 002504b8 01cc0015 R_PPC64_JMP_SLOT __csinieee128 + 0 00250500 01f30015 R_PPC64_JMP_SLOT __sinhieee128 + 0 00250570 022a0015 R_PPC64_JMP_SLOT __asinieee128 + 0 00250580 022d0015 R_PPC64_JMP_SLOT __roundieee128 + 0 002505a0 023e0015 R_PPC64_JMP_SLOT __logieee128 + 0 002505c8 02490015 R_PPC64_JMP_SLOT __tanieee128 + 0 00250630 02750015 R_PPC64_JMP_SLOT __ccosieee128 + 0 00250670 028a0015 R_PPC64_JMP_SLOT __log10ieee128 + 0 002506c8 02bd0015 R_PPC64_JMP_SLOT __cexpieee128 + 0 002506d8 02c80015 R_PPC64_JMP_SLOT __coshieee128 + 0 002509b0 03ef0015 R_PPC64_JMP_SLOT __truncieee128 + 0 00250af8 04a60015 R_PPC64_JMP_SLOT __expieee128 + 0 00250b50 04c60015 R_PPC64_JMP_SLOT __fmodieee128 + 0 00250bb0 04e70015 R_PPC64_JMP_SLOT __tanhieee128 + 0 00250c38 05130015 R_PPC64_JMP_SLOT __acosieee128 + 0 00250ce0 05540015 R_PPC64_JMP_SLOT __sinieee128 + 0 00250d60 057e0015 R_PPC64_JMP_SLOT __atanieee128 + 0 00250dd8 05b10015 R_PPC64_JMP_SLOT __sqrtieee128 + 0 00250e98 06020015 R_PPC64_JMP_SLOT __cosieee128 + 0 00250eb0 060a0015 R_PPC64_JMP_SLOT __atanhieee128 + 0 00250ef0 06200015 R_PPC64_JMP_SLOT __asinhieee128 + 0 00250fd8 0
Re: [power-ieee128] RFH: LTO broken
On Fri, Jan 07, 2022 at 12:29:25PM +0100, Jakub Jelinek wrote: > we don't do it consistently: > readelf -Wr > /home/jakub/gcc/obj38/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5.0.0 > | grep ieee128 > 00250310 01280015 R_PPC64_JMP_SLOT > __atan2ieee128 + 0 > 00250340 01420015 R_PPC64_JMP_SLOT > __clogieee128 + 0 > 00250438 01a30015 R_PPC64_JMP_SLOT > __acoshieee128 + 0 > 002504b8 01cc0015 R_PPC64_JMP_SLOT > __csinieee128 + 0 > 00250500 01f30015 R_PPC64_JMP_SLOT > __sinhieee128 + 0 > 00250570 022a0015 R_PPC64_JMP_SLOT > __asinieee128 + 0 > 00250580 022d0015 R_PPC64_JMP_SLOT > __roundieee128 + 0 > 002505a0 023e0015 R_PPC64_JMP_SLOT > __logieee128 + 0 > 002505c8 02490015 R_PPC64_JMP_SLOT > __tanieee128 + 0 > 00250630 02750015 R_PPC64_JMP_SLOT > __ccosieee128 + 0 > 00250670 028a0015 R_PPC64_JMP_SLOT > __log10ieee128 + 0 > 002506c8 02bd0015 R_PPC64_JMP_SLOT > __cexpieee128 + 0 > 002506d8 02c80015 R_PPC64_JMP_SLOT > __coshieee128 + 0 > 002509b0 03ef0015 R_PPC64_JMP_SLOT > __truncieee128 + 0 > 00250af8 04a60015 R_PPC64_JMP_SLOT > __expieee128 + 0 > 00250b50 04c60015 R_PPC64_JMP_SLOT > __fmodieee128 + 0 > 00250bb0 04e70015 R_PPC64_JMP_SLOT > __tanhieee128 + 0 > 00250c38 05130015 R_PPC64_JMP_SLOT > __acosieee128 + 0 > 00250ce0 05540015 R_PPC64_JMP_SLOT > __sinieee128 + 0 > 00250d60 057e0015 R_PPC64_JMP_SLOT > __atanieee128 + 0 > 00250dd8 05b10015 R_PPC64_JMP_SLOT > __sqrtieee128 + 0 > 00250e98 06020015 R_PPC64_JMP_SLOT > __cosieee128 + 0 > 00250eb0 060a0015 R_PPC64_JMP_SLOT > __atanhieee128 + 0 > 00250ef0 06200015 R_PPC64_JMP_SLOT > __asinhieee128 + 0 > 00250fd8 067f0015 R_PPC64_JMP_SLOT > __csqrtieee128 + 0 > 00251038 06ad0015 R_PPC64_JMP_SLOT > __cabsieee128 + 0 > All these should for POWER_IEEE128 use atan2q@QUADMATH_1.0 etc. So, seems all these come from f951 compiled sources. For user code, I think the agreement was if you want to use successfully -mabi=ieeelongdouble, you need glibc 2.32 or later, which is why the Fortran FE doesn't conditionalize on whether glibc 2.32 is available or not and just emits __WHATEVERieee128 entrypoints. But for Fortran compiled sources in libgfortran, we need to use __WHATEVERieee128 only if glibc 2.32 or later and WHATEVERq (from libquadmath) otherwise. I guess easiest would be to do this always in the FE, but we need to determine in the FE if the target is glibc 2.32 or later. > On the other side, on glibc 2.32+ build, we still use some libquadmath APIs > when we shouldn't: > readelf -Wr > /home/jakub/gcc/obj/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5 > | grep QUADMATH > 002502c8 00260015 R_PPC64_JMP_SLOT > fmaq@QUADMATH_1.0 + 0 > 002505f8 00670015 R_PPC64_JMP_SLOT > tanq@QUADMATH_1.0 + 0 > 00250930 009b0015 R_PPC64_JMP_SLOT > fabsq@QUADMATH_1.0 + 0 > 00250940 009d0015 R_PPC64_JMP_SLOT > sinq@QUADMATH_1.0 + 0 > 00250c98 00cf0015 R_PPC64_JMP_SLOT > copysignq@QUADMATH_1.0 + 0 > 00251038 01070015 R_PPC64_JMP_SLOT > cosq@QUADMATH_1.0 + 0 > 00251068 010a0015 R_PPC64_JMP_SLOT > fmodq@QUADMATH_1.0 + 0 > These should use __fmaieee128, __tanieee128 etc. instead. This one seems easily fixed by the following patch, ok for power-ieee128? 2022-01-07 Jakub Jelinek * libgfortran.h (__copysignieee128, __fmaieee128, __fmodieee128): Declare. * intrinsics/trigd.c (COPYSIGN, FMOD, FABS, FMA, SIN, COS, TAN): If POWER_IEEE128 is defined, define these for kind 17 include. * intrinsics/trigd_lib.inc (COPYSIGN, FMOD, FABS, FMA, SIN, COS, TAN): Don't define if COPYSIGN is already defined. --- libgfortran/libgfortran.h.jj2022-01-07 09:39:10.222157644 + +++ libgfort
Re: [power-ieee128] RFH: LTO broken
Hi Jakub, 00251038 06ad0015 R_PPC64_JMP_SLOT __cabsieee128 + 0 All these should for POWER_IEEE128 use atan2q@QUADMATH_1.0 etc. So, seems all these come from f951 compiled sources. For user code, I think the agreement was if you want to use successfully -mabi=ieeelongdouble, you need glibc 2.32 or later, which is why the Fortran FE doesn't conditionalize on whether glibc 2.32 is available or not and just emits __WHATEVERieee128 entrypoints. That was the idea, I think. But for Fortran compiled sources in libgfortran, we need to use __WHATEVERieee128 only if glibc 2.32 or later and WHATEVERq (from libquadmath) otherwise. I guess easiest would be to do this always in the FE, but we need to determine in the FE if the target is glibc 2.32 or later. Instead of determining this in the front end, maybe we can add an option (documented, but marked as useful as only for internal use and with no guarantee that it will remain) and use that option when compiling libgfortran. On the other side, on glibc 2.32+ build, we still use some libquadmath APIs when we shouldn't: readelf -Wr /home/jakub/gcc/obj/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5 | grep QUADMATH 002502c8 00260015 R_PPC64_JMP_SLOT fmaq@QUADMATH_1.0 + 0 002505f8 00670015 R_PPC64_JMP_SLOT tanq@QUADMATH_1.0 + 0 00250930 009b0015 R_PPC64_JMP_SLOT fabsq@QUADMATH_1.0 + 0 00250940 009d0015 R_PPC64_JMP_SLOT sinq@QUADMATH_1.0 + 0 00250c98 00cf0015 R_PPC64_JMP_SLOT copysignq@QUADMATH_1.0 + 0 00251038 01070015 R_PPC64_JMP_SLOT cosq@QUADMATH_1.0 + 0 00251068 010a0015 R_PPC64_JMP_SLOT fmodq@QUADMATH_1.0 + 0 These should use __fmaieee128, __tanieee128 etc. instead. This one seems easily fixed by the following patch, ok for power-ieee128? OK! Best regards Thomas
Re: [power-ieee128] RFH: LTO broken
On Fri, Jan 07, 2022 at 03:25:57PM +0100, Thomas Koenig wrote:
> > > 00251038 06ad0015 R_PPC64_JMP_SLOT
> > > __cabsieee128 + 0
> > > All these should for POWER_IEEE128 use atan2q@QUADMATH_1.0 etc.
> >
> > So, seems all these come from f951 compiled sources.
> > For user code, I think the agreement was if you want to use successfully
> > -mabi=ieeelongdouble, you need glibc 2.32 or later, which is why the Fortran
> > FE doesn't conditionalize on whether glibc 2.32 is available or not and just
> > emits __WHATEVERieee128 entrypoints.
>
> That was the idea, I think.
>
> > But for Fortran compiled sources in libgfortran, we need to use
> > __WHATEVERieee128 only if glibc 2.32 or later and WHATEVERq (from
> > libquadmath) otherwise.
> > I guess easiest would be to do this always in the FE, but we need to
> > determine in the FE if the target is glibc 2.32 or later.
>
> Instead of determining this in the front end, maybe we can add
> an option (documented, but marked as useful as only for internal
> use and with no guarantee that it will remain) and use that option
> when compiling libgfortran.
We apparently have already TARGET_GLIBC_MAJOR and TARGET_GLIBC_MINOR target
macros, and e.g. libgcc or D testsuite uses internal options like
-fbuilding-libgcc.
So, the following patch adds -fbuilding-libgfortran option and uses
it together with TARGET_GLIBC_M* checks to decide whether to use
libquadmath APIs (for the IEEE quad kind=16 if -fbuilding-libgfortran
and not glibc or glibc is older than 2.32) or glibc 2.32 APIs
(otherwise). This way, libgfortran uses solely the libquadmath APIs
on glibc < 2.32 and __*ieee128 APIs on glibc 2.32, while user code
always uses the latter.
Ok for power-ieee128?
2022-01-07 Jakub Jelinek
gcc/fortran/
* trans-types.c (gfc_init_kinds): When setting abi_kind to 17, if not
targetting glibc 2.32 or later and -fbuilding-libgfortran, set
gfc_real16_is_float128 and c_float128 in gfc_real_kinds.
(gfc_build_real_type): Don't set c_long_double if c_float128 is
already set.
* trans-intrinsic.c (builtin_decl_for_precision): Don't use
long_double_built_in if gfc_real16_is_float128 and
long_double_type_node == gfc_float128_type_node.
* lang.opt (fbuilding-libgfortran): New undocumented option.
libgfortran/
* Makefile.am (AM_FCFLAGS): Add -fbuilding-libgfortran after
-fallow-leading-underscore.
* Makefile.in: Regenerated.
--- gcc/fortran/trans-types.c.jj2022-01-04 10:27:56.498322942 +
+++ gcc/fortran/trans-types.c 2022-01-07 16:19:06.737066905 +
@@ -516,7 +516,16 @@ gfc_init_kinds (void)
{
for (int i = 0; i < r_index; ++i)
if (gfc_real_kinds[i].kind == 16)
- gfc_real_kinds[i].abi_kind = 17;
+ {
+ gfc_real_kinds[i].abi_kind = 17;
+ if (flag_building_libgfortran
+ && (TARGET_GLIBC_MAJOR < 2
+ || (TARGET_GLIBC_MAJOR == 2 && TARGET_GLIBC_MINOR < 32)))
+ {
+ gfc_real16_is_float128 = true;
+ gfc_real_kinds[i].c_float128 = 1;
+ }
+ }
}
/* Choose the default integer kind. We choose 4 unless the user directs us
@@ -859,7 +868,7 @@ gfc_build_real_type (gfc_real_info *info
info->c_float = 1;
if (mode_precision == DOUBLE_TYPE_SIZE)
info->c_double = 1;
- if (mode_precision == LONG_DOUBLE_TYPE_SIZE)
+ if (mode_precision == LONG_DOUBLE_TYPE_SIZE && !info->c_float128)
info->c_long_double = 1;
if (mode_precision != LONG_DOUBLE_TYPE_SIZE && mode_precision == 128)
{
--- gcc/fortran/trans-intrinsic.c.jj2022-01-07 09:39:10.222157644 +
+++ gcc/fortran/trans-intrinsic.c 2022-01-07 13:57:35.451495059 +
@@ -154,7 +154,9 @@ builtin_decl_for_precision (enum built_i
i = m->float_built_in;
else if (precision == TYPE_PRECISION (double_type_node))
i = m->double_built_in;
- else if (precision == TYPE_PRECISION (long_double_type_node))
+ else if (precision == TYPE_PRECISION (long_double_type_node)
+ && (!gfc_real16_is_float128
+ || long_double_type_node != gfc_float128_type_node))
i = m->long_double_built_in;
else if (precision == TYPE_PRECISION (gfc_float128_type_node))
{
--- gcc/fortran/lang.opt.jj 2021-12-31 11:00:15.042190365 +
+++ gcc/fortran/lang.opt2022-01-07 16:18:17.685995005 +
@@ -413,6 +413,9 @@ fblas-matmul-limit=
Fortran RejectNegative Joined UInteger Var(flag_blas_matmul_limit) Init(30)
-fblas-matmul-limit=Size of the smallest matrix for which matmul
will use BLAS.
+fbuilding-libgfortran
+Fortran Undocumented Var(flag_building_libgfortran)
+
fcheck-array-temporaries
Fortran
Produce a warning at runtime if a array temporary has been created for a
procedure argument.
--- libgfortran/Makefile.am.jj 2022-01-04 10:27:56.498322942 +
+++ libgfortran/Makefile.am 202
Re: [power-ieee128] RFH: LTO broken
Hi Jakub, So, the following patch adds -fbuilding-libgfortran option and uses it together with TARGET_GLIBC_M* checks to decide whether to use libquadmath APIs (for the IEEE quad kind=16 if -fbuilding-libgfortran and not glibc or glibc is older than 2.32) or glibc 2.32 APIs (otherwise). This way, libgfortran uses solely the libquadmath APIs on glibc < 2.32 and __*ieee128 APIs on glibc 2.32, while user code always uses the latter. Ok for power-ieee128? OK! Best regards Thomas
