| Message ID | 20220103200026.GW2646553@tucnak |
|---|---|
| State | New |
| Headers | show |
| Series | [power-ieee128] libgfortran, fortran: -mabi=ieeelongdouble I/O | expand |
Hi Jakub, > 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 that a couple of files still do not have the correct flags set when compiling, or maybe some types are wrong. This is now something that can be debugged in detail. > Ok? OK. And thanks! Best regards Thomas
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
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.
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 <meissner@linux.ibm.com> | 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 <meissner@the-meissners.org> * 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)
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.
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
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
On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote: > > On 06.01.22 06:00, Michael Meissner via Fortran wrote: > 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. So, what's the plan for that? Can't find CONVERT= in Fortran 2018, so I assume it is a non-standard extension, https://www.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/language-reference/file-operation-i-o-statements/open-statement-specifiers/open-convert-specifier.html#open-convert-specifier documents the Intel one and we accept CONVERT='native' CONVERT='swap' CONVERT='big_endian' CONVERT='little_endian' Now, I suppose for powerpc64le we want to add some more, but the question is how they play together with the byteswapping and how to name them, so that it is clear they talk about REAL/COMPLEX KIND=16 format and nothing else. Can we (or do we) want to allow multiple comma separated strings from the orthogonal choices, like CONVERT='big_endian,ibm_extended' CONVERT='swap,ieee_extended' or add ibm_extended, ieee_extended and strings that combine those with swap, big_endian and little_endian ibm_extended_swap, ieee_extended_little etc.? Jakub
On 07.01.22 10:22, Jakub Jelinek wrote: > On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote: >> >> On 06.01.22 06:00, Michael Meissner via Fortran wrote: >> 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. > > So, what's the plan for that? > Can't find CONVERT= in Fortran 2018, so I assume it is a non-standard > extension, Correct. > https://www.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/language-reference/file-operation-i-o-statements/open-statement-specifiers/open-convert-specifier.html#open-convert-specifier > documents the Intel one We followed Intel on that one. NAG also has it (although the details differ). > and we accept > CONVERT='native' > CONVERT='swap' > CONVERT='big_endian' > CONVERT='little_endian' > Now, I suppose for powerpc64le we want to add > some more, but the question is how they play together > with the byteswapping and how to name them, so that > it is clear they talk about REAL/COMPLEX KIND=16 format > and nothing else. Can we (or do we) want to allow > multiple comma separated strings from the orthogonal > choices, like > CONVERT='big_endian,ibm_extended' > CONVERT='swap,ieee_extended' > or add ibm_extended, ieee_extended and strings that > combine those with swap, big_endian and little_endian > ibm_extended_swap, ieee_extended_little etc.? In https://gcc.gnu.org/pipermail/fortran/2021-October/056895.html I made a suggestion how how the format could look like. I used a plus sign instead of a comma because I thought the environment variable should follow the same syntax as the CONVERT specifier, and I did not want to think about having commas in there :-) Thinking about this again after some time, I think the syntax of the environment variable would be clearer if the keywords for the two conversions were separate, so somethig like big_endian;r16_ieee;r16_ibm:10-20; for the environment variable and CONVERT="big_endian,r16_ibm" would probably be better. Best regards Thomas
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 0000000000251268 000005e400000026 R_PPC64_ADDR64 0000000000000000 quadmath_snprintf@QUADMATH_1.0 + 0 0000000000251270 0000030600000026 R_PPC64_ADDR64 0000000000000000 strtoflt128@QUADMATH_1.0 + 0 00000000002502e0 0000011600000015 R_PPC64_JMP_SLOT 0000000000000000 ynq@QUADMATH_1.0 + 0 0000000000250390 0000016000000015 R_PPC64_JMP_SLOT 0000000000000000 sqrtq@QUADMATH_1.0 + 0 0000000000250508 000001fa00000015 R_PPC64_JMP_SLOT 0000000000000000 fmaq@QUADMATH_1.0 + 0 0000000000250530 0000021200000015 R_PPC64_JMP_SLOT 0000000000000000 fabsq@QUADMATH_1.0 + 0 0000000000250760 0000030600000015 R_PPC64_JMP_SLOT 0000000000000000 strtoflt128@QUADMATH_1.0 + 0 0000000000250990 000003df00000015 R_PPC64_JMP_SLOT 0000000000000000 cosq@QUADMATH_1.0 + 0 00000000002509f0 0000040a00000015 R_PPC64_JMP_SLOT 0000000000000000 expq@QUADMATH_1.0 + 0 0000000000250a88 0000045100000015 R_PPC64_JMP_SLOT 0000000000000000 erfcq@QUADMATH_1.0 + 0 0000000000250a98 0000045e00000015 R_PPC64_JMP_SLOT 0000000000000000 jnq@QUADMATH_1.0 + 0 0000000000250ac8 0000047e00000015 R_PPC64_JMP_SLOT 0000000000000000 sinq@QUADMATH_1.0 + 0 0000000000250e38 000005db00000015 R_PPC64_JMP_SLOT 0000000000000000 fmodq@QUADMATH_1.0 + 0 0000000000250e48 000005e000000015 R_PPC64_JMP_SLOT 0000000000000000 tanq@QUADMATH_1.0 + 0 0000000000250e58 000005e400000015 R_PPC64_JMP_SLOT 0000000000000000 quadmath_snprintf@QUADMATH_1.0 + 0 0000000000250f20 0000062900000015 R_PPC64_JMP_SLOT 0000000000000000 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 0000000000250310 0000012800000015 R_PPC64_JMP_SLOT 0000000000000000 __atan2ieee128 + 0 0000000000250340 0000014200000015 R_PPC64_JMP_SLOT 0000000000000000 __clogieee128 + 0 0000000000250438 000001a300000015 R_PPC64_JMP_SLOT 0000000000000000 __acoshieee128 + 0 00000000002504b8 000001cc00000015 R_PPC64_JMP_SLOT 0000000000000000 __csinieee128 + 0 0000000000250500 000001f300000015 R_PPC64_JMP_SLOT 0000000000000000 __sinhieee128 + 0 0000000000250570 0000022a00000015 R_PPC64_JMP_SLOT 0000000000000000 __asinieee128 + 0 0000000000250580 0000022d00000015 R_PPC64_JMP_SLOT 0000000000000000 __roundieee128 + 0 00000000002505a0 0000023e00000015 R_PPC64_JMP_SLOT 0000000000000000 __logieee128 + 0 00000000002505c8 0000024900000015 R_PPC64_JMP_SLOT 0000000000000000 __tanieee128 + 0 0000000000250630 0000027500000015 R_PPC64_JMP_SLOT 0000000000000000 __ccosieee128 + 0 0000000000250670 0000028a00000015 R_PPC64_JMP_SLOT 0000000000000000 __log10ieee128 + 0 00000000002506c8 000002bd00000015 R_PPC64_JMP_SLOT 0000000000000000 __cexpieee128 + 0 00000000002506d8 000002c800000015 R_PPC64_JMP_SLOT 0000000000000000 __coshieee128 + 0 00000000002509b0 000003ef00000015 R_PPC64_JMP_SLOT 0000000000000000 __truncieee128 + 0 0000000000250af8 000004a600000015 R_PPC64_JMP_SLOT 0000000000000000 __expieee128 + 0 0000000000250b50 000004c600000015 R_PPC64_JMP_SLOT 0000000000000000 __fmodieee128 + 0 0000000000250bb0 000004e700000015 R_PPC64_JMP_SLOT 0000000000000000 __tanhieee128 + 0 0000000000250c38 0000051300000015 R_PPC64_JMP_SLOT 0000000000000000 __acosieee128 + 0 0000000000250ce0 0000055400000015 R_PPC64_JMP_SLOT 0000000000000000 __sinieee128 + 0 0000000000250d60 0000057e00000015 R_PPC64_JMP_SLOT 0000000000000000 __atanieee128 + 0 0000000000250dd8 000005b100000015 R_PPC64_JMP_SLOT 0000000000000000 __sqrtieee128 + 0 0000000000250e98 0000060200000015 R_PPC64_JMP_SLOT 0000000000000000 __cosieee128 + 0 0000000000250eb0 0000060a00000015 R_PPC64_JMP_SLOT 0000000000000000 __atanhieee128 + 0 0000000000250ef0 0000062000000015 R_PPC64_JMP_SLOT 0000000000000000 __asinhieee128 + 0 0000000000250fd8 0000067f00000015 R_PPC64_JMP_SLOT 0000000000000000 __csqrtieee128 + 0 0000000000251038 000006ad00000015 R_PPC64_JMP_SLOT 0000000000000000 __cabsieee128 + 0 All these should for POWER_IEEE128 use atan2q@QUADMATH_1.0 etc. 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 00000000002502c8 0000002600000015 R_PPC64_JMP_SLOT 0000000000000000 fmaq@QUADMATH_1.0 + 0 00000000002505f8 0000006700000015 R_PPC64_JMP_SLOT 0000000000000000 tanq@QUADMATH_1.0 + 0 0000000000250930 0000009b00000015 R_PPC64_JMP_SLOT 0000000000000000 fabsq@QUADMATH_1.0 + 0 0000000000250940 0000009d00000015 R_PPC64_JMP_SLOT 0000000000000000 sinq@QUADMATH_1.0 + 0 0000000000250c98 000000cf00000015 R_PPC64_JMP_SLOT 0000000000000000 copysignq@QUADMATH_1.0 + 0 0000000000251038 0000010700000015 R_PPC64_JMP_SLOT 0000000000000000 cosq@QUADMATH_1.0 + 0 0000000000251068 0000010a00000015 R_PPC64_JMP_SLOT 0000000000000000 fmodq@QUADMATH_1.0 + 0 These should use __fmaieee128, __tanieee128 etc. instead. Jakub
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 > 0000000000250310 0000012800000015 R_PPC64_JMP_SLOT 0000000000000000 __atan2ieee128 + 0 > 0000000000250340 0000014200000015 R_PPC64_JMP_SLOT 0000000000000000 __clogieee128 + 0 > 0000000000250438 000001a300000015 R_PPC64_JMP_SLOT 0000000000000000 __acoshieee128 + 0 > 00000000002504b8 000001cc00000015 R_PPC64_JMP_SLOT 0000000000000000 __csinieee128 + 0 > 0000000000250500 000001f300000015 R_PPC64_JMP_SLOT 0000000000000000 __sinhieee128 + 0 > 0000000000250570 0000022a00000015 R_PPC64_JMP_SLOT 0000000000000000 __asinieee128 + 0 > 0000000000250580 0000022d00000015 R_PPC64_JMP_SLOT 0000000000000000 __roundieee128 + 0 > 00000000002505a0 0000023e00000015 R_PPC64_JMP_SLOT 0000000000000000 __logieee128 + 0 > 00000000002505c8 0000024900000015 R_PPC64_JMP_SLOT 0000000000000000 __tanieee128 + 0 > 0000000000250630 0000027500000015 R_PPC64_JMP_SLOT 0000000000000000 __ccosieee128 + 0 > 0000000000250670 0000028a00000015 R_PPC64_JMP_SLOT 0000000000000000 __log10ieee128 + 0 > 00000000002506c8 000002bd00000015 R_PPC64_JMP_SLOT 0000000000000000 __cexpieee128 + 0 > 00000000002506d8 000002c800000015 R_PPC64_JMP_SLOT 0000000000000000 __coshieee128 + 0 > 00000000002509b0 000003ef00000015 R_PPC64_JMP_SLOT 0000000000000000 __truncieee128 + 0 > 0000000000250af8 000004a600000015 R_PPC64_JMP_SLOT 0000000000000000 __expieee128 + 0 > 0000000000250b50 000004c600000015 R_PPC64_JMP_SLOT 0000000000000000 __fmodieee128 + 0 > 0000000000250bb0 000004e700000015 R_PPC64_JMP_SLOT 0000000000000000 __tanhieee128 + 0 > 0000000000250c38 0000051300000015 R_PPC64_JMP_SLOT 0000000000000000 __acosieee128 + 0 > 0000000000250ce0 0000055400000015 R_PPC64_JMP_SLOT 0000000000000000 __sinieee128 + 0 > 0000000000250d60 0000057e00000015 R_PPC64_JMP_SLOT 0000000000000000 __atanieee128 + 0 > 0000000000250dd8 000005b100000015 R_PPC64_JMP_SLOT 0000000000000000 __sqrtieee128 + 0 > 0000000000250e98 0000060200000015 R_PPC64_JMP_SLOT 0000000000000000 __cosieee128 + 0 > 0000000000250eb0 0000060a00000015 R_PPC64_JMP_SLOT 0000000000000000 __atanhieee128 + 0 > 0000000000250ef0 0000062000000015 R_PPC64_JMP_SLOT 0000000000000000 __asinhieee128 + 0 > 0000000000250fd8 0000067f00000015 R_PPC64_JMP_SLOT 0000000000000000 __csqrtieee128 + 0 > 0000000000251038 000006ad00000015 R_PPC64_JMP_SLOT 0000000000000000 __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 > 00000000002502c8 0000002600000015 R_PPC64_JMP_SLOT 0000000000000000 fmaq@QUADMATH_1.0 + 0 > 00000000002505f8 0000006700000015 R_PPC64_JMP_SLOT 0000000000000000 tanq@QUADMATH_1.0 + 0 > 0000000000250930 0000009b00000015 R_PPC64_JMP_SLOT 0000000000000000 fabsq@QUADMATH_1.0 + 0 > 0000000000250940 0000009d00000015 R_PPC64_JMP_SLOT 0000000000000000 sinq@QUADMATH_1.0 + 0 > 0000000000250c98 000000cf00000015 R_PPC64_JMP_SLOT 0000000000000000 copysignq@QUADMATH_1.0 + 0 > 0000000000251038 0000010700000015 R_PPC64_JMP_SLOT 0000000000000000 cosq@QUADMATH_1.0 + 0 > 0000000000251068 0000010a00000015 R_PPC64_JMP_SLOT 0000000000000000 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 <jakub@redhat.com> * 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.jj 2022-01-07 09:39:10.222157644 +0000 +++ libgfortran/libgfortran.h 2022-01-07 12:58:57.604483761 +0000 @@ -1956,6 +1956,8 @@ extern __float128 __atanhieee128 (__floa __attribute__ ((__nothrow__, __leaf__)); extern __float128 __atanieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __copysignieee128 (__float128, __float128) + __attribute__ ((__nothrow__, __leaf__)); extern __float128 __coshieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); extern __float128 __cosieee128 (__float128) @@ -1968,6 +1970,10 @@ extern __float128 __expieee128 (__float1 __attribute__ ((__nothrow__, __leaf__)); extern __float128 __fabsieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __fmaieee128 (__float128, __float128, __float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __fmodieee128 (__float128, __float128) + __attribute__ ((__nothrow__, __leaf__)); extern __float128 __jnieee128 (int, __float128) __attribute__ ((__nothrow__, __leaf__)); extern __float128 __log10ieee128 (__float128) --- libgfortran/intrinsics/trigd.c.jj 2022-01-07 09:39:10.222157644 +0000 +++ libgfortran/intrinsics/trigd.c 2022-01-07 12:57:01.311939084 +0000 @@ -313,6 +313,16 @@ see the files COPYING3 and COPYING.RUNTI #define HAVE_INFINITY_KIND #endif +#ifdef POWER_IEEE128 +#define COPYSIGN __copysignieee128 +#define FMOD __fmodieee128 +#define FABS __fabsieee128 +#define FMA __fmaieee128 +#define SIN __sinieee128 +#define COS __cosieee128 +#define TAN __tanieee128 +#endif + #include "trigd_lib.inc" #undef KIND --- libgfortran/intrinsics/trigd_lib.inc.jj 2021-12-31 11:00:58.083137032 +0000 +++ libgfortran/intrinsics/trigd_lib.inc 2022-01-07 12:56:25.491155265 +0000 @@ -65,6 +65,7 @@ PIO180L -- lower bits of p #define CONCAT(x,y) x ## y #define CONCAT_EXPAND(x,y) CONCAT(x,y) +#ifndef COPYSIGN #define COPYSIGN LITERAL(copysign) #define FMOD LITERAL(fmod) #define FABS LITERAL(fabs) @@ -72,6 +73,7 @@ PIO180L -- lower bits of p #define SIN LITERAL(sin) #define COS LITERAL(cos) #define TAN LITERAL(tan) +#endif #ifdef TINY #define TINY_LITERAL LITERAL(TINY) Jakub
Hi Jakub, >> 0000000000251038 000006ad00000015 R_PPC64_JMP_SLOT 0000000000000000 __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 >> 00000000002502c8 0000002600000015 R_PPC64_JMP_SLOT 0000000000000000 fmaq@QUADMATH_1.0 + 0 >> 00000000002505f8 0000006700000015 R_PPC64_JMP_SLOT 0000000000000000 tanq@QUADMATH_1.0 + 0 >> 0000000000250930 0000009b00000015 R_PPC64_JMP_SLOT 0000000000000000 fabsq@QUADMATH_1.0 + 0 >> 0000000000250940 0000009d00000015 R_PPC64_JMP_SLOT 0000000000000000 sinq@QUADMATH_1.0 + 0 >> 0000000000250c98 000000cf00000015 R_PPC64_JMP_SLOT 0000000000000000 copysignq@QUADMATH_1.0 + 0 >> 0000000000251038 0000010700000015 R_PPC64_JMP_SLOT 0000000000000000 cosq@QUADMATH_1.0 + 0 >> 0000000000251068 0000010a00000015 R_PPC64_JMP_SLOT 0000000000000000 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
On Fri, Jan 07, 2022 at 03:25:57PM +0100, Thomas Koenig wrote: > > > 0000000000251038 000006ad00000015 R_PPC64_JMP_SLOT 0000000000000000 __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 <jakub@redhat.com> 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.jj 2022-01-04 10:27:56.498322942 +0000 +++ gcc/fortran/trans-types.c 2022-01-07 16:19:06.737066905 +0000 @@ -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.jj 2022-01-07 09:39:10.222157644 +0000 +++ gcc/fortran/trans-intrinsic.c 2022-01-07 13:57:35.451495059 +0000 @@ -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 +0000 +++ gcc/fortran/lang.opt 2022-01-07 16:18:17.685995005 +0000 @@ -413,6 +413,9 @@ fblas-matmul-limit= Fortran RejectNegative Joined UInteger Var(flag_blas_matmul_limit) Init(30) -fblas-matmul-limit=<n> 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 +0000 +++ libgfortran/Makefile.am 2022-01-07 16:23:20.052602554 +0000 @@ -1079,8 +1079,8 @@ endif $(patsubst %.c,%.lo,$(notdir $(i_matmull_c))): AM_CFLAGS += -funroll-loops # Add the -fallow-leading-underscore option when needed -$(patsubst %.F90,%.lo,$(patsubst %.f90,%.lo,$(notdir $(gfor_specific_src)))): AM_FCFLAGS += -fallow-leading-underscore -selected_real_kind.lo selected_int_kind.lo: AM_FCFLAGS += -fallow-leading-underscore +$(patsubst %.F90,%.lo,$(patsubst %.f90,%.lo,$(notdir $(gfor_specific_src)))): AM_FCFLAGS += -fallow-leading-underscore -fbuilding-libgfortran +selected_real_kind.lo selected_int_kind.lo: AM_FCFLAGS += -fallow-leading-underscore -fbuilding-libgfortran # Build *_r17.F90 and *_c17.F90 with additional -mabi=ieeelongdouble on powerpc64le-linux. @@ -1097,7 +1097,7 @@ endif if IEEE_SUPPORT # Add flags for IEEE modules -$(patsubst %.F90,%.lo,$(notdir $(gfor_ieee_src))): AM_FCFLAGS += -Wno-unused-dummy-argument -Wno-c-binding-type -ffree-line-length-0 -fallow-leading-underscore +$(patsubst %.F90,%.lo,$(notdir $(gfor_ieee_src))): AM_FCFLAGS += -Wno-unused-dummy-argument -Wno-c-binding-type -ffree-line-length-0 -fallow-leading-underscore -fbuilding-libgfortran endif # Dependencies between IEEE_ARITHMETIC and IEEE_EXCEPTIONS --- libgfortran/Makefile.in.jj 2022-01-04 10:27:56.508323161 +0000 +++ libgfortran/Makefile.in 2022-01-07 16:23:50.853275633 +0000 @@ -7633,8 +7633,8 @@ $(patsubst %.c,%.lo,$(notdir $(i_matmul_ $(patsubst %.c,%.lo,$(notdir $(i_matmull_c))): AM_CFLAGS += -funroll-loops # Add the -fallow-leading-underscore option when needed -$(patsubst %.F90,%.lo,$(patsubst %.f90,%.lo,$(notdir $(gfor_specific_src)))): AM_FCFLAGS += -fallow-leading-underscore -selected_real_kind.lo selected_int_kind.lo: AM_FCFLAGS += -fallow-leading-underscore +$(patsubst %.F90,%.lo,$(patsubst %.f90,%.lo,$(notdir $(gfor_specific_src)))): AM_FCFLAGS += -fallow-leading-underscore -fbuilding-libgfortran +selected_real_kind.lo selected_int_kind.lo: AM_FCFLAGS += -fallow-leading-underscore -fbuilding-libgfortran # Build *_r17.F90 and *_c17.F90 with additional -mabi=ieeelongdouble on powerpc64le-linux. @@ -7648,7 +7648,7 @@ selected_real_kind.lo selected_int_kind. @HAVE_REAL_17_TRUE@$(patsubst %_c17.c,%_c17.lo,$(notdir $(gfor_built_src))): AM_CFLAGS += -mabi=ieeelongdouble # Add flags for IEEE modules -@IEEE_SUPPORT_TRUE@$(patsubst %.F90,%.lo,$(notdir $(gfor_ieee_src))): AM_FCFLAGS += -Wno-unused-dummy-argument -Wno-c-binding-type -ffree-line-length-0 -fallow-leading-underscore +@IEEE_SUPPORT_TRUE@$(patsubst %.F90,%.lo,$(notdir $(gfor_ieee_src))): AM_FCFLAGS += -Wno-unused-dummy-argument -Wno-c-binding-type -ffree-line-length-0 -fallow-leading-underscore -fbuilding-libgfortran # Dependencies between IEEE_ARITHMETIC and IEEE_EXCEPTIONS ieee_arithmetic.lo: ieee/ieee_arithmetic.F90 ieee_exceptions.lo Jakub
On Fri, Jan 07, 2022 at 11:26:15AM +0100, Thomas Koenig wrote: > In > > https://gcc.gnu.org/pipermail/fortran/2021-October/056895.html > > I made a suggestion how how the format could look like. I used > a plus sign instead of a comma because I thought the environment > variable should follow the same syntax as the CONVERT specifier, > and I did not want to think about having commas in there :-) > > Thinking about this again after some time, I think the syntax of > the environment variable would be clearer if the keywords for > the two conversions were separate, so somethig like > > big_endian;r16_ieee;r16_ibm:10-20; > > for the environment variable and > > CONVERT="big_endian,r16_ibm" > > would probably be better. Here is completely untested patch that implements something, but doesn't implement the gcc option stuff, nor the CONVERT= syntax to supply multiple conversion options nor done anything about env var nor any testcases. But it tries to have the native/swap/big/little choice orthogonal from native/r16_ieee/r16_ibm with r16_ieee and r16_ibm only supported on ppc64le-linux. For INQUIRE it has the so far perhaps manageable set of possibilities handled so that it uses string literals and doesn't have to construct those strings at runtime (haven't studied how it would need to be done). I'm afraid I don't know that stuff enough to move forward from this. --- gcc/fortran/libgfortran.h.jj 2022-01-07 18:41:55.473722388 +0100 +++ gcc/fortran/libgfortran.h 2022-01-07 19:14:23.881784305 +0100 @@ -86,14 +86,16 @@ along with GCC; see the file COPYING3. #define GFC_INVALID_UNIT -3 /* Possible values for the CONVERT I/O specifier. */ -/* Keep in sync with GFC_FLAG_CONVERT_* in gcc/flags.h. */ +/* Keep in sync with GFC_FLAG_CONVERT_* in gcc/flag-types.h. */ typedef enum { GFC_CONVERT_NONE = -1, GFC_CONVERT_NATIVE = 0, GFC_CONVERT_SWAP, GFC_CONVERT_BIG, - GFC_CONVERT_LITTLE + GFC_CONVERT_LITTLE, + GFC_CONVERT_R16_IEEE = 4, + GFC_CONVERT_R16_IBM = 8 } unit_convert; --- gcc/flag-types.h.jj 2022-01-07 18:41:55.452722678 +0100 +++ gcc/flag-types.h 2022-01-07 19:13:55.953170776 +0100 @@ -424,7 +424,9 @@ enum gfc_convert GFC_FLAG_CONVERT_NATIVE = 0, GFC_FLAG_CONVERT_SWAP, GFC_FLAG_CONVERT_BIG, - GFC_FLAG_CONVERT_LITTLE + GFC_FLAG_CONVERT_LITTLE, + GFC_FLAG_CONVERT_R16_IEEE = 4, + GFC_FLAG_CONVERT_R16_IBM = 8 }; --- libgfortran/io/open.c.jj 2022-01-07 18:41:56.078714031 +0100 +++ libgfortran/io/open.c 2022-01-07 19:19:11.582780100 +0100 @@ -153,6 +153,10 @@ static const st_option convert_opt[] = { "swap", GFC_CONVERT_SWAP}, { "big_endian", GFC_CONVERT_BIG}, { "little_endian", GFC_CONVERT_LITTLE}, +#ifdef HAVE_GFC_REAL_17 + { "r16_ieee", GFC_CONVERT_R16_IEEE}, + { "r16_ibm", GFC_CONVERT_R16_IBM}, +#endif { NULL, 0} }; @@ -820,7 +824,14 @@ st_open (st_parameter_open *opp) else conv = compile_options.convert; } - + + flags.convert = 0; + +#ifdef HAVE_GFC_REAL_17 + flags.convert = conv & (GFC_CONVERT_R16_IEEE | GFC_CONVERT_R16_IBM); + conv &= ~(GFC_CONVERT_R16_IEEE | GFC_CONVERT_R16_IBM); +#endif + switch (conv) { case GFC_CONVERT_NATIVE: @@ -840,7 +851,7 @@ st_open (st_parameter_open *opp) break; } - flags.convert = conv; + flags.convert |= conv; if (flags.position != POSITION_UNSPECIFIED && flags.access == ACCESS_DIRECT) --- libgfortran/io/transfer.c.jj 2022-01-07 18:41:56.080714003 +0100 +++ libgfortran/io/transfer.c 2022-01-07 20:43:36.146920392 +0100 @@ -1126,7 +1126,11 @@ unformatted_read (st_parameter_dt *dtp, size *= GFC_SIZE_OF_CHAR_KIND(kind); read_block_direct (dtp, dest, size * nelems); - if (unlikely (dtp->u.p.current_unit->flags.convert == GFC_CONVERT_SWAP) + int convert = dtp->u.p.current_unit->flags.convert; +#ifdef HAVE_GFC_REAL_17 + convert &= ~(GFC_CONVERT_R16_IEEE | GFC_CONVERT_R16_IBM); +#endif + if (unlikely (convert == GFC_CONVERT_SWAP) && kind != 1) { /* Handle wide chracters. */ @@ -1144,6 +1148,48 @@ unformatted_read (st_parameter_dt *dtp, } bswap_array (dest, dest, size, nelems); } +#ifdef HAVE_GFC_REAL_17 + if ((dtp->u.p.current_unit->flags.convert & GFC_CONVERT_R16_IEEE) + && kind == 16 + && (type == BT_REAL || type == BT_COMPLEX)) + { + if (type == BT_COMPLEX && size == 32) + { + nelems *= 2; + size /= 2; + } + char *pd = dest; + for (size_t i = 0; i < nelems; i++) + { + GFC_REAL_16 r16; + GFC_REAL_17 r17; + memcpy (&r17, pd, 16); + r16 = r17; + memcpy (pd, &r16, 16); + pd += size; + } + } + else if ((dtp->u.p.current_unit->flags.convert & GFC_CONVERT_R16_IBM) + && kind == 17 + && (type == BT_REAL || type == BT_COMPLEX)) + { + if (type == BT_COMPLEX && size == 32) + { + nelems *= 2; + size /= 2; + } + char *pd = dest; + for (size_t i = 0; i < nelems; i++) + { + GFC_REAL_16 r16; + GFC_REAL_17 r17; + memcpy (&r16, pd, 16); + r17 = r16; + memcpy (pd, &r17, 16); + pd += size; + } + } +#endif } @@ -1233,9 +1279,50 @@ unformatted_write (st_parameter_dt *dtp, else nc = nrem; - bswap_array (buffer, p, size, nc); +#ofdef HAVE_GFC_REAL_17 + if ((dtp->u.p.current_unit->flags.convert & GFC_CONVERT_R16_IEEE) + && kind == 16 + && (type == BT_REAL || type == BT_COMPLEX)) + { + for (size_t i = 0; i < nc; i++) + { + GFC_REAL_16 r16; + GFC_REAL_17 r17; + memcpy (&r16, p, 16); + r17 = r16; + memcpy (&buffer[i * 16], &r17, 16); + p += 16; + } + if ((dtp->u.p.current_unit->flags.convert + & ~(GFC_CONVERT_R16_IEEE | GFC_CONVERT_R16_IBM)) + == GFC_CONVERT_SWAP) + bswap_array (buffer, buffer, size, nc); + } + else if ((dtp->u.p.current_unit->flags.convert & GFC_CONVERT_R16_IBM) + && kind == 17 + && (type == BT_REAL || type == BT_COMPLEX)) + { + for (size_t i = 0; i < nc; i++) + { + GFC_REAL_16 r16; + GFC_REAL_17 r17; + memcpy (&r17, p, 16); + r16 = r17; + memcpy (&buffer[i * 16], &r16, 16); + p += 16; + } + if ((dtp->u.p.current_unit->flags.convert + & ~(GFC_CONVERT_R16_IEEE | GFC_CONVERT_R16_IBM)) + == GFC_CONVERT_SWAP) + bswap_array (buffer, buffer, size, nc); + } + else +#endif + { + bswap_array (buffer, p, size, nc); + p += size * nc; + } write_buf (dtp, buffer, size * nc); - p += size * nc; nrem -= nc; } while (nrem > 0); @@ -2691,8 +2778,12 @@ us_read (st_parameter_dt *dtp, int conti return; } + int convert = dtp->u.p.current_unit->flags.convert; +#ifdef HAVE_GFC_REAL_17 + convert &= ~(GFC_CONVERT_R16_IEEE | GFC_CONVERT_R16_IBM); +#endif /* Only GFC_CONVERT_NATIVE and GFC_CONVERT_SWAP are valid here. */ - if (likely (dtp->u.p.current_unit->flags.convert == GFC_CONVERT_NATIVE)) + if (likely (convert == GFC_CONVERT_NATIVE)) { switch (nr) { @@ -2894,6 +2985,13 @@ data_transfer_init (st_parameter_dt *dtp if (conv == GFC_CONVERT_NONE) conv = compile_options.convert; + u_flags.convert = 0; + +#ifdef HAVE_GFC_REAL_17 + flags.convert = conv & (GFC_CONVERT_R16_IEEE | GFC_CONVERT_R16_IBM); + conv &= ~(GFC_CONVERT_R16_IEEE | GFC_CONVERT_R16_IBM); +#endif + switch (conv) { case GFC_CONVERT_NATIVE: @@ -2913,7 +3011,7 @@ data_transfer_init (st_parameter_dt *dtp break; } - u_flags.convert = conv; + u_flags.convert |= conv; opp.common = dtp->common; opp.common.flags &= IOPARM_COMMON_MASK; @@ -3710,8 +3808,12 @@ write_us_marker (st_parameter_dt *dtp, c else len = compile_options.record_marker; + int convert = dtp->u.p.current_unit->flags.convert; +#ifdef HAVE_GFC_REAL_17 + convert &= ~(GFC_CONVERT_R16_IEEE | GFC_CONVERT_R16_IBM); +#endif /* Only GFC_CONVERT_NATIVE and GFC_CONVERT_SWAP are valid here. */ - if (likely (dtp->u.p.current_unit->flags.convert == GFC_CONVERT_NATIVE)) + if (likely (convert == GFC_CONVERT_NATIVE)) { switch (len) { --- libgfortran/io/inquire.c.jj 2022-01-07 18:41:56.077714045 +0100 +++ libgfortran/io/inquire.c 2022-01-07 19:25:23.015604303 +0100 @@ -642,6 +642,24 @@ inquire_via_unit (st_parameter_inquire * p = __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ ? "LITTLE_ENDIAN" : "BIG_ENDIAN"; break; +#ifdef HAVE_GFC_REAL_17 + case GFC_CONVERT_NATIVE | GFC_CONVERT_R16_IEEE: + p = __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ ? "BIG_ENDIAN+R16_IEEE" : "LITTLE_ENDIAN+R16_IEEE"; + break; + + case GFC_CONVERT_SWAP | GFC_CONVERT_R16_IEEE: + p = __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ ? "LITTLE_ENDIAN+R16_IEEE" : "BIG_ENDIAN+R16_IEEE"; + break; + + case GFC_CONVERT_NATIVE | GFC_CONVERT_R16_IBM: + p = __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ ? "BIG_ENDIAN+R16_IBM" : "LITTLE_ENDIAN+R16_IBM"; + break; + + case GFC_CONVERT_SWAP | GFC_CONVERT_R16_IBM: + p = __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ ? "LITTLE_ENDIAN+R16_IBM" : "BIG_ENDIAN+R16_IBM"; + break; +#endif + default: internal_error (&iqp->common, "inquire_via_unit(): Bad convert"); } --- libgfortran/io/file_pos.c.jj 2022-01-07 18:41:56.077714045 +0100 +++ libgfortran/io/file_pos.c 2022-01-07 19:22:50.466730018 +0100 @@ -104,6 +104,11 @@ unformatted_backspace (st_parameter_file ssize_t length; int continued; char p[sizeof (GFC_INTEGER_8)]; + int convert = u->flags.convert; + +#ifdef HAVE_GFC_REAL_17 + convert &= ~(GFC_CONVERT_R16_IEEE | GFC_CONVERT_R16_IBM); +#endif if (compile_options.record_marker == 0) length = sizeof (GFC_INTEGER_4); @@ -119,7 +124,7 @@ unformatted_backspace (st_parameter_file goto io_error; /* Only GFC_CONVERT_NATIVE and GFC_CONVERT_SWAP are valid here. */ - if (likely (u->flags.convert == GFC_CONVERT_NATIVE)) + if (likely (convert == GFC_CONVERT_NATIVE)) { switch (length) { Jakub
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
On 07.01.22 20:52, Jakub Jelinek wrote: > Here is completely untested patch that implements something, > but doesn't implement the gcc option stuff, nor the CONVERT= > syntax to supply multiple conversion options nor done anything > about env var nor any testcases. > > But it tries to have the native/swap/big/little choice orthogonal from > native/r16_ieee/r16_ibm with r16_ieee and r16_ibm only supported on > ppc64le-linux. > > For INQUIRE it has the so far perhaps manageable set of possibilities > handled so that it uses string literals and doesn't have to construct > those strings at runtime (haven't studied how it would need to be done). > > I'm afraid I don't know that stuff enough to move forward from this. That looks like the direction to go. I will take it from there and see if I can find some hours over the weekend to work on something. Unfortunately, my daytime job will kick in again on Monday :-) One thing that one has to watch out for is a big-endian IBM long double file, so the byte swapping will have to be done before assigning the value. Best regards Thomas
On Fri, Jan 07, 2022 at 10:40:50PM +0100, Thomas Koenig wrote: > One thing that one has to watch out for is a big-endian IBM long double > file, so the byte swapping will have to be done before assigning > the value. I've tried to handle that right, i.e. on unformatted read with byte-swapping and r16 <-> r17 conversions first do byte-swapping and then r16 <-> r17 conversions, while for unformatted writes first r16 <-> r17 conversions and then byte-swapping. Jakub
On 07.01.22 22:48, Jakub Jelinek wrote: > On Fri, Jan 07, 2022 at 10:40:50PM +0100, Thomas Koenig wrote: >> One thing that one has to watch out for is a big-endian IBM long double >> file, so the byte swapping will have to be done before assigning >> the value. > > I've tried to handle that right, i.e. on unformatted read with > byte-swapping and r16 <-> r17 conversions first do byte-swapping > and then r16 <-> r17 conversions, while for unformatted writes > first r16 <-> r17 conversions and then byte-swapping. I have tried to unravel the different cases here, I count six (lumping together the environment variables, the CONVERT specifier and -fconvert, and leaving out the byte swapping) Compiler Convert Read action Write action IEEE None None None IEEE IEEE None None IEEE IBM IBM->IEEE IEEE->IBM IBM None None None IBM IEEE IEEE->IBM IBM->IEEE IBM IBM None None From this table, it is clear that the compiler has to inform the library about the option it is using, I think it is best encoded in the number passed to _gfortran_set_convert. Old programs should continue to run with the new library, so the absence of a call to _gfortran_set_convert, or a call which sets byte swapping, should have the old meaning, i.e IBM long double. A program which uses IEEE long double should then call _gfortran_set_convert with a suitable argument to let the library know what to do, just in case. I think this is what I will start working on. Best regards Thomas
On Sat, Jan 08, 2022 at 11:07:24AM +0100, Thomas Koenig wrote: > I have tried to unravel the different cases here, I count six > (lumping together the environment variables, the CONVERT specifier > and -fconvert, and leaving out the byte swapping) > > Compiler Convert Read action Write action > > IEEE None None None > IEEE IEEE None None > IEEE IBM IBM->IEEE IEEE->IBM > > IBM None None None > IBM IEEE IEEE->IBM IBM->IEEE > IBM IBM None None > > From this table, it is clear that the compiler has to inform > the library about the option it is using, I think it is best > encoded in the number passed to _gfortran_set_convert. Whether the compiler is using IEEE or IBM real(kind=16) or complex(kind=16) for a particular spot (which doesn't have to be the same in the whole program) is known to the library by the kind argument it provides to the I/O routines, if it is kind=16, it is IBM, if it is kind=17, it is IEEE. See the patch I've posted, which does one thing when the runtime kind (i.e. abi_kind on the compiler side) is 17 and convert says r16_ibm, and another thing when runtime kind is 16 and convert says r16_ieee. Other cases shouldn't need conversion. And IMHO the default like for byte-swapping should be the native format, i.e. the one the program actually used. The only thing that should be encoded in _gfortran_set_convert is -fconvertWHATEVER command line option IMO. Jakub
On Sat, Jan 08, 2022 at 12:00:38PM +0100, Jakub Jelinek via Gcc-patches wrote: > And IMHO the default like for byte-swapping should be the native > format, i.e. the one the program actually used. One reason for that is that neither conversion is lossless, neither format is a subset or superset of the other. Yes, IEEE quad has both much bigger exponent range (-16382..16383 vs. -1022..1023) and slightly bigger fixed precision (113 vs. 106 bits). But IBM extended has that weirdo numerically awful flexible precision where certain numbers can have much bigger precision than those 106 bits, up to 2048+52 or so. So there is rounding in both directions. So, after distros switch to -mabi=ieeelongdouble by default or when people use -mabi=ieeelongdouble on their programs, they'd better store that format into data files by default, without the need of some magic CONVERT= options, env vars or command line options. Only in the case where they need to interact with -mabi=ibmlongdouble environments, they need to take some action. Jakub
On Sat, Jan 08, 2022 at 12:10:56PM +0100, Jakub Jelinek via Gcc-patches wrote: > One reason for that is that neither conversion is lossless, neither format > is a subset or superset of the other. Yes, IEEE quad has both much bigger > exponent range (-16382..16383 vs. -1022..1023) and slightly bigger fixed > precision (113 vs. 106 bits). > But IBM extended has that weirdo numerically awful flexible precision where > certain numbers can have much bigger precision than those 106 bits, up to > 2048+52 or so. So there is rounding in both directions. > So, after distros switch to -mabi=ieeelongdouble by default or when people > use -mabi=ieeelongdouble on their programs, they'd better store that format > into data files by default, without the need of some magic CONVERT= options, > env vars or command line options. Only in the case where they need to > interact with -mabi=ibmlongdouble environments, they need to take some > action. Note, as for byteswapping, apparently it wasn't ever working right fox the IBM extended real(kind=16) and complex(kind=16). Because unlike IEEE extended or integral types, it seems powerpc*-*-* doesn't actually fully byteswap those between little and big endian. Proof: long double a = 0.3333333333333333333333333333333333333333333333333333333333333333333333333333L; compiled little endian IBM long double: .size a, 16 a: .long 1431655765 .long 1070945621 .long 1431655766 .long 1014322517 compiled big endian IBM long double: .size a, 16 a: .long 1070945621 .long 1431655765 .long 1014322517 .long 1431655766 compiled little endian IEEE long double: .size a, 16 a: .long 1431655765 .long 1431655765 .long 1431655765 .long 1073567061 compiled big endian IEEE long double: .size a, 16 a: .long 1073567061 .long 1431655765 .long 1431655765 .long 1431655765 where the numbers in .long arguments are 32-bit numbers stored in the selected endianity. Compiled with -mlong-double-64 little endian: .size a, 8 a: .long 1431655765 .long 1070945621 and big endian: .size a, 8 a: .long 1070945621 .long 1431655765 Unless I'm misreading this, for IEEE long double, or double (and I bet float too) byteswapping the whole numbers is what is needed for interoperability between powerpc64{,le}-linux, for IBM long double we'd actually want to byteswap it as 2 real(kind=8) numbers and not one real(kind=16) one, i.e. the numbers are always stored as the more significant double followed by less significant double in memory. Jakub
On 08.01.22 15:02, Jakub Jelinek via Fortran wrote: > Note, as for byteswapping, apparently it wasn't ever working right fox > the IBM extended real(kind=16) and complex(kind=16). The lack of bug reports since the conversion feature was introduced in 2006, more than 15 years ago, tells us something, I guess...
On Sat, Jan 08, 2022 at 03:13:10PM +0100, Thomas Koenig wrote: > > On 08.01.22 15:02, Jakub Jelinek via Fortran wrote: > > Note, as for byteswapping, apparently it wasn't ever working right fox > > the IBM extended real(kind=16) and complex(kind=16). > > The lack of bug reports since the conversion feature was introduced in > 2006, more than 15 years ago, tells us something, I guess... powerpc64le was only introduced in GCC 4.8 in 2013, so slightly less than that, but still. Either nobody interchanges/shares fortran unformatted data between powerpc big and little endian, or if they do, they don't use real(kind=16) or complex(kind=16) in there... Jakub
On Sat, Jan 08, 2022 at 03:18:07PM +0100, Jakub Jelinek wrote: > On Sat, Jan 08, 2022 at 03:13:10PM +0100, Thomas Koenig wrote: > > > > On 08.01.22 15:02, Jakub Jelinek via Fortran wrote: > > > Note, as for byteswapping, apparently it wasn't ever working right fox > > > the IBM extended real(kind=16) and complex(kind=16). > > > > The lack of bug reports since the conversion feature was introduced in > > 2006, more than 15 years ago, tells us something, I guess... > > powerpc64le was only introduced in GCC 4.8 in 2013, so slightly less > than that, but still. > Either nobody interchanges/shares fortran unformatted data between > powerpc big and little endian, or if they do, they don't use real(kind=16) > or complex(kind=16) in there... I still wish I had had the forethought when we were setting up the LE ABI to change the default 128-bit format to IEEE instead of IBM. But alas, I didn't. You would still need converters between the big endian IBM format and little endian IEEE format, but it would have avoided a lot of the problems where GCC assumes there is only one floating point format for each size.
On Sat, Jan 8, 2022 at 1:59 PM Michael Meissner <meissner@linux.ibm.com> wrote: > > On Sat, Jan 08, 2022 at 03:18:07PM +0100, Jakub Jelinek wrote: > > On Sat, Jan 08, 2022 at 03:13:10PM +0100, Thomas Koenig wrote: > > > > > > On 08.01.22 15:02, Jakub Jelinek via Fortran wrote: > > > > Note, as for byteswapping, apparently it wasn't ever working right fox > > > > the IBM extended real(kind=16) and complex(kind=16). > > > > > > The lack of bug reports since the conversion feature was introduced in > > > 2006, more than 15 years ago, tells us something, I guess... > > > > powerpc64le was only introduced in GCC 4.8 in 2013, so slightly less > > than that, but still. > > Either nobody interchanges/shares fortran unformatted data between > > powerpc big and little endian, or if they do, they don't use real(kind=16) > > or complex(kind=16) in there... > > I still wish I had had the forethought when we were setting up the LE ABI to > change the default 128-bit format to IEEE instead of IBM. But alas, I didn't. > You would still need converters between the big endian IBM format and little > endian IEEE format, but it would have avoided a lot of the problems where GCC > assumes there is only one floating point format for each size. Mike, The LE ABI initial target was Power8 and IEEE128 hardware support was added to Power9. The ABI was a conscious decision. IEEE 128 was not a viable requirement for the LE ABI at the time of the transition. Thanks, David
On Sat, Jan 08, 2022 at 02:15:14PM -0500, David Edelsohn wrote: > On Sat, Jan 8, 2022 at 1:59 PM Michael Meissner <meissner@linux.ibm.com> wrote: > > > > On Sat, Jan 08, 2022 at 03:18:07PM +0100, Jakub Jelinek wrote: > > > On Sat, Jan 08, 2022 at 03:13:10PM +0100, Thomas Koenig wrote: > > > > > > > > On 08.01.22 15:02, Jakub Jelinek via Fortran wrote: > > > > > Note, as for byteswapping, apparently it wasn't ever working right fox > > > > > the IBM extended real(kind=16) and complex(kind=16). > > > > > > > > The lack of bug reports since the conversion feature was introduced in > > > > 2006, more than 15 years ago, tells us something, I guess... > > > > > > powerpc64le was only introduced in GCC 4.8 in 2013, so slightly less > > > than that, but still. > > > Either nobody interchanges/shares fortran unformatted data between > > > powerpc big and little endian, or if they do, they don't use real(kind=16) > > > or complex(kind=16) in there... > > > > I still wish I had had the forethought when we were setting up the LE ABI to > > change the default 128-bit format to IEEE instead of IBM. But alas, I didn't. > > You would still need converters between the big endian IBM format and little > > endian IEEE format, but it would have avoided a lot of the problems where GCC > > assumes there is only one floating point format for each size. > > Mike, > > The LE ABI initial target was Power8 and IEEE128 hardware support was > added to Power9. The ABI was a conscious decision. IEEE 128 was not a > viable requirement for the LE ABI at the time of the transition. Yes I know, but my memory is we (the GCC group within IBM) at least knew that IEEE 128-bit was coming towards the end of the ABI definition period. But perhaps not. In any case, it doesn't much matter now, as it is all ancient history.
--- gcc/fortran/trans-io.c.jj 2021-12-31 11:00:15.052190585 +0000 +++ gcc/fortran/trans-io.c 2022-01-03 14:20:55.238159269 +0000 @@ -1765,18 +1765,17 @@ transfer_namelist_element (stmtblock_t * else tmp = build_int_cst (gfc_charlen_type_node, 0); + int abi_kind = gfc_type_abi_kind (ts); if (dtio_proc == null_pointer_node) - tmp = build_call_expr_loc (input_location, - iocall[IOCALL_SET_NML_VAL], 6, - dt_parm_addr, addr_expr, string, - build_int_cst (gfc_int4_type_node, ts->kind), - tmp, dtype); + tmp = build_call_expr_loc (input_location, iocall[IOCALL_SET_NML_VAL], 6, + dt_parm_addr, addr_expr, string, + build_int_cst (gfc_int4_type_node, abi_kind), + tmp, dtype); else - tmp = build_call_expr_loc (input_location, - iocall[IOCALL_SET_NML_DTIO_VAL], 8, - dt_parm_addr, addr_expr, string, - build_int_cst (gfc_int4_type_node, ts->kind), - tmp, dtype, dtio_proc, vtable); + tmp = build_call_expr_loc (input_location, iocall[IOCALL_SET_NML_DTIO_VAL], + 8, dt_parm_addr, addr_expr, string, + build_int_cst (gfc_int4_type_node, abi_kind), + tmp, dtype, dtio_proc, vtable); gfc_add_expr_to_block (block, tmp); /* If the object is an array, transfer rank times: @@ -2298,7 +2297,7 @@ transfer_expr (gfc_se * se, gfc_typespec ts->kind = gfc_index_integer_kind; } - kind = ts->kind; + kind = gfc_type_abi_kind (ts); function = NULL; arg2 = NULL; arg3 = NULL; @@ -2318,14 +2317,14 @@ transfer_expr (gfc_se * se, gfc_typespec arg2 = build_int_cst (integer_type_node, kind); if (last_dt == READ) { - if (gfc_real16_is_float128 && ts->kind == 16) + if ((gfc_real16_is_float128 && kind == 16) || kind == 17) function = iocall[IOCALL_X_REAL128]; else function = iocall[IOCALL_X_REAL]; } else { - if (gfc_real16_is_float128 && ts->kind == 16) + if ((gfc_real16_is_float128 && kind == 16) || kind == 17) function = iocall[IOCALL_X_REAL128_WRITE]; else function = iocall[IOCALL_X_REAL_WRITE]; @@ -2337,14 +2336,14 @@ transfer_expr (gfc_se * se, gfc_typespec arg2 = build_int_cst (integer_type_node, kind); if (last_dt == READ) { - if (gfc_real16_is_float128 && ts->kind == 16) + if ((gfc_real16_is_float128 && kind == 16) || kind == 17) function = iocall[IOCALL_X_COMPLEX128]; else function = iocall[IOCALL_X_COMPLEX]; } else { - if (gfc_real16_is_float128 && ts->kind == 16) + if ((gfc_real16_is_float128 && kind == 16) || kind == 17) function = iocall[IOCALL_X_COMPLEX128_WRITE]; else function = iocall[IOCALL_X_COMPLEX_WRITE]; --- libgfortran/io/size_from_kind.c.jj 2021-12-31 11:00:58.083137032 +0000 +++ libgfortran/io/size_from_kind.c 2021-12-31 16:19:50.182058780 +0000 @@ -49,6 +49,10 @@ size_from_real_kind (int kind) case 16: return sizeof (GFC_REAL_16); #endif +#ifdef HAVE_GFC_REAL_17 + case 17: + return sizeof (GFC_REAL_17); +#endif default: return kind; } @@ -76,6 +80,10 @@ size_from_complex_kind (int kind) case 16: return sizeof (GFC_COMPLEX_16); #endif +#ifdef HAVE_GFC_COMPLEX_17 + case 17: + return sizeof (GFC_COMPLEX_17); +#endif default: return 2 * kind; } --- libgfortran/io/io.h.jj 2021-12-31 11:00:58.083137032 +0000 +++ libgfortran/io/io.h 2021-12-31 16:26:44.181125298 +0000 @@ -1063,7 +1063,8 @@ default_width_for_float (int kind) { case 4: return 15; case 8: return 25; - case 16: return 42; + case 16: + case 17: return 42; default: return 0; } } @@ -1075,7 +1076,8 @@ default_precision_for_float (int kind) { case 4: return 7; case 8: return 16; - case 16: return 33; + case 16: + case 17: return 33; default: return 0; } } --- libgfortran/io/read.c.jj 2021-12-31 11:08:19.052835974 +0000 +++ libgfortran/io/read.c 2022-01-03 12:12:19.999171427 +0000 @@ -47,6 +47,14 @@ set_integer (void *dest, GFC_INTEGER_LAR switch (length) { #ifdef HAVE_GFC_INTEGER_16 +#ifdef HAVE_GFC_REAL_17 + case 17: + { + GFC_INTEGER_16 tmp = value; + memcpy (dest, (void *) &tmp, 16); + } + break; +#endif /* length=10 comes about for kind=10 real/complex BOZ, cf. PR41711. */ case 10: case 16: @@ -96,7 +104,14 @@ si_max (int length) #endif switch (length) - { + { +#if defined HAVE_GFC_REAL_17 + case 17: + value = 1; + for (int n = 1; n < 4 * 16; n++) + value = (value << 2) + 3; + return value; +#endif #if defined HAVE_GFC_REAL_16 || defined HAVE_GFC_REAL_10 case 16: case 10: @@ -181,6 +196,15 @@ convert_real (st_parameter_dt *dtp, void # endif #endif +#if defined(HAVE_GFC_REAL_17) + case 17: +# if defined(POWER_IEEE128) + *((GFC_REAL_17*) dest) = __strtoieee128 (buffer, &endptr); +# else + *((GFC_REAL_17*) dest) = __qmath_(strtoflt128) (buffer, &endptr); +# endif +#endif + default: internal_error (&dtp->common, "Unsupported real kind during IO"); } @@ -260,6 +284,15 @@ convert_infnan (st_parameter_dt *dtp, vo # endif #endif +#if defined(HAVE_GFC_REAL_17) + case 17: + if (is_inf) + *((GFC_REAL_17*) dest) = plus ? __builtin_infl () : -__builtin_infl (); + else + *((GFC_REAL_17*) dest) = plus ? __builtin_nanl ("") : -__builtin_nanl (""); + break; +#endif + default: internal_error (&dtp->common, "Unsupported real kind during IO"); } @@ -1225,6 +1258,12 @@ zero: break; #endif +#ifdef HAVE_GFC_REAL_17 + case 17: + *((GFC_REAL_17 *) dest) = 0.0; + break; +#endif + default: internal_error (&dtp->common, "Unsupported real kind during IO"); } --- libgfortran/io/write.c.jj 2021-12-31 11:08:19.052835974 +0000 +++ libgfortran/io/write.c 2022-01-03 13:28:40.269478670 +0000 @@ -649,6 +649,15 @@ extract_uint (const void *p, int len) i = (GFC_UINTEGER_16) tmp; } break; +# ifdef HAVE_GFC_REAL_17 + case 17: + { + GFC_INTEGER_16 tmp = 0; + memcpy ((void *) &tmp, p, 16); + i = (GFC_UINTEGER_16) tmp; + } + break; +# endif #endif default: internal_error (NULL, "bad integer kind"); @@ -1518,6 +1527,9 @@ size_from_kind (st_parameter_dt *dtp, co size = 4932 + 3; break; case 16: +#ifdef HAVE_GFC_REAL_17 + case 17: +#endif size = 4932 + 3; break; default: @@ -1674,6 +1686,13 @@ set_fnode_default (st_parameter_dt *dtp, f->u.real.e = 4; #endif break; +#ifdef HAVE_GFC_REAL_17 + case 17: + f->u.real.w = 45; + f->u.real.d = 36; + f->u.real.e = 4; + break; +#endif default: internal_error (&dtp->common, "bad real kind"); break; --- libgfortran/io/write_float.def.jj 2021-12-31 11:00:58.093137252 +0000 +++ libgfortran/io/write_float.def 2022-01-03 14:33:12.694336419 +0000 @@ -834,8 +834,16 @@ snprintf (buffer, size, "%+-#.*e", (prec snprintf (buffer, size, "%+-#.*Le", (prec), (val)) -#if defined(GFC_REAL_16_IS_FLOAT128) -#define DTOA2Q(prec,val) \ +#if defined(HAVE_GFC_REAL_17) +# if defined(POWER_IEEE128) +# define DTOA2Q(prec,val) \ +__snprintfieee128 (buffer, size, "%+-#.*Le", (prec), (val)) +# else +# define DTOA2Q(prec,val) \ +quadmath_snprintf (buffer, size, "%+-#.*Qe", (prec), (val)) +# endif +#elif defined(GFC_REAL_16_IS_FLOAT128) +# define DTOA2Q(prec,val) \ quadmath_snprintf (buffer, size, "%+-#.*Qe", (prec), (val)) #endif @@ -849,10 +857,17 @@ snprintf (buffer, size, "%+-#.*f", (prec snprintf (buffer, size, "%+-#.*Lf", (prec), (val)) -#if defined(GFC_REAL_16_IS_FLOAT128) -#define FDTOA2Q(prec,val) \ -quadmath_snprintf (buffer, size, "%+-#.*Qf", \ - (prec), (val)) +#if defined(HAVE_GFC_REAL_17) +# if defined(POWER_IEEE128) +# define FDTOA2Q(prec,val) \ +__snprintfieee128 (buffer, size, "%+-#.*Lf", (prec), (val)) +# else +# define FDTOA2Q(prec,val) \ +quadmath_snprintf (buffer, size, "%+-#.*Qf", (prec), (val)) +# endif +#elif defined(GFC_REAL_16_IS_FLOAT128) +# define FDTOA2Q(prec,val) \ +quadmath_snprintf (buffer, size, "%+-#.*Qf", (prec), (val)) #endif @@ -925,6 +940,11 @@ determine_en_precision (st_parameter_dt # endif break; #endif +#ifdef HAVE_GFC_REAL_17 + case 17: + EN_PREC(16,Q) +#endif + break; default: internal_error (NULL, "bad real kind"); } @@ -1128,6 +1148,11 @@ get_float_string (st_parameter_dt *dtp, # endif break; #endif +#ifdef HAVE_GFC_REAL_17 + case 17: + FORMAT_FLOAT(16,Q) + break; +#endif default: internal_error (NULL, "bad real kind"); } --- libgfortran/io/transfer128.c.jj 2021-12-31 11:00:58.083137032 +0000 +++ libgfortran/io/transfer128.c 2022-01-03 14:40:41.734177007 +0000 @@ -28,7 +28,7 @@ see the files COPYING3 and COPYING.RUNTI #include "io.h" -#if defined(GFC_REAL_16_IS_FLOAT128) +#if defined(GFC_REAL_16_IS_FLOAT128) || defined(HAVE_GFC_REAL_17) /* The prototypes for the called procedures in transfer.c. */ @@ -65,8 +65,10 @@ export_proto(transfer_complex128_write); write_float; the pointer assignment with USED attribute make sure that there is a non-weakref dependence if the quadmath functions are used. That avoids segfault when libquadmath is statically linked. */ +# if !defined(HAVE_GFC_REAL_17) || !defined(POWER_IEEE128) static void __attribute__((used)) *tmp1 = strtoflt128; static void __attribute__((used)) *tmp2 = quadmath_snprintf; +# endif void transfer_real128 (st_parameter_dt *dtp, void *p, int kind) --- libgfortran/libgfortran.h.jj 2021-12-31 11:45:06.121158716 +0000 +++ libgfortran/libgfortran.h 2022-01-03 14:32:45.063730903 +0000 @@ -1936,28 +1936,54 @@ internal_proto(cshift1_16_c17); /* Prototypes for the POWER __ieee128 functions. */ #ifdef POWER_IEEE128 -extern __float128 __acoshieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __acosieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __asinhieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __asinieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __atan2ieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __atanhieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __atanieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __coshieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __cosieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __erfieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __expieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __fabsieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __jnieee128 (int, __float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __log10ieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __logieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __powieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __sinhieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __sinieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __sqrtieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __tanhieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __tanieee128 (__float128) __attribute__ ((__nothrow__, __leaf__)); -extern __float128 __ynieee128 (int , __float128) __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __acoshieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __acosieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __asinhieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __asinieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __atan2ieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __atanhieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __atanieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __coshieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __cosieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __erfieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __expieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __fabsieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __jnieee128 (int, __float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __log10ieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __logieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __powieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __sinhieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __sinieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __sqrtieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __tanhieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __tanieee128 (__float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __ynieee128 (int , __float128) + __attribute__ ((__nothrow__, __leaf__)); +extern __float128 __strtoieee128 (const char *, char **) + __attribute__ ((__nothrow__, __leaf__)); +extern int __snprintfieee128 (char *, size_t, const char *, ...) + __attribute__ ((__nothrow__)); #endif --- libgfortran/Makefile.am.jj 2021-12-31 11:08:19.032835533 +0000 +++ libgfortran/Makefile.am 2022-01-03 19:00:55.266791438 +0000 @@ -8,18 +8,26 @@ gcc_version := $(shell @get_gcc_base_ver ## Symbol versioning (copied from libssp). if LIBGFOR_USE_SYMVER +# -Wc is only a libtool option. +comma = , +PREPROCESS = $(subst -Wc$(comma), , $(COMPILE)) -E + +gfortran.ver: $(srcdir)/gfortran.map kinds.inc + $(EGREP) -v '#(#| |$$)' $< | \ + $(PREPROCESS) -P -include config.h -include kinds.inc - > $@ || (rm -f $@ ; exit 1) + if LIBGFOR_USE_SYMVER_GNU -version_arg = -Wl,--version-script=$(srcdir)/gfortran.map -version_dep = $(srcdir)/gfortran.map +version_arg = -Wl,--version-script=gfortran.ver +version_dep = gfortran.ver endif if LIBGFOR_USE_SYMVER_SUN -version_arg = -Wl,-M,gfortran.map-sun -version_dep = gfortran.map-sun -gfortran.map-sun : $(srcdir)/gfortran.map \ +version_arg = -Wl,-M,gfortran.ver-sun +version_dep = gfortran.ver-sun gfortran.ver +gfortran.map-sun : gfortran.ver \ $(top_srcdir)/../contrib/make_sunver.pl \ $(libgfortran_la_OBJECTS) $(libgfortran_la_LIBADD) perl $(top_srcdir)/../contrib/make_sunver.pl \ - $(srcdir)/gfortran.map \ + gfortran.ver \ $(libgfortran_la_OBJECTS:%.lo=.libs/%.o) \ `echo $(libgfortran_la_LIBADD) | \ sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \ @@ -1103,7 +1111,7 @@ ieee_arithmetic.mod: ieee_arithmetic.lo : BUILT_SOURCES=$(gfor_built_src) $(gfor_built_specific_src) \ - $(gfor_built_specific2_src) $(gfor_misc_specifics) + $(gfor_built_specific2_src) $(gfor_misc_specifics) $(version_dep) prereq_SRC = $(gfor_src) $(gfor_built_src) $(gfor_io_src) \ $(gfor_helper_src) $(gfor_ieee_src) $(gfor_io_headers) $(gfor_specific_src) --- libgfortran/Makefile.in.jj 2021-12-31 11:08:19.032835533 +0000 +++ libgfortran/Makefile.in 2022-01-03 19:01:42.907836363 +0000 @@ -739,12 +739,16 @@ top_builddir = @top_builddir@ top_srcdir = @top_srcdir@ ACLOCAL_AMFLAGS = -I .. -I ../config gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER) + +# -Wc is only a libtool option. +@LIBGFOR_USE_SYMVER_TRUE@comma = , +@LIBGFOR_USE_SYMVER_TRUE@PREPROCESS = $(subst -Wc$(comma), , $(COMPILE)) -E @LIBGFOR_USE_SYMVER_FALSE@version_arg = -@LIBGFOR_USE_SYMVER_GNU_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_arg = -Wl,--version-script=$(srcdir)/gfortran.map -@LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_arg = -Wl,-M,gfortran.map-sun +@LIBGFOR_USE_SYMVER_GNU_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_arg = -Wl,--version-script=gfortran.ver +@LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_arg = -Wl,-M,gfortran.ver-sun @LIBGFOR_USE_SYMVER_FALSE@version_dep = -@LIBGFOR_USE_SYMVER_GNU_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = $(srcdir)/gfortran.map -@LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = gfortran.map-sun +@LIBGFOR_USE_SYMVER_GNU_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = gfortran.ver +@LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = gfortran.ver-sun gfortran.ver gfor_c_HEADERS = ISO_Fortran_binding.h gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) \ @@ -1648,7 +1652,7 @@ intrinsics/random_init.f90 BUILT_SOURCES = $(gfor_built_src) $(gfor_built_specific_src) \ $(gfor_built_specific2_src) $(gfor_misc_specifics) \ - $(am__append_7) + $(version_dep) $(am__append_7) prereq_SRC = $(gfor_src) $(gfor_built_src) $(gfor_io_src) \ $(gfor_helper_src) $(gfor_ieee_src) $(gfor_io_headers) $(gfor_specific_src) @@ -7607,11 +7611,15 @@ uninstall-am: uninstall-cafexeclibLTLIBR .PRECIOUS: Makefile -@LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@gfortran.map-sun : $(srcdir)/gfortran.map \ + +@LIBGFOR_USE_SYMVER_TRUE@gfortran.ver: $(srcdir)/gfortran.map kinds.inc +@LIBGFOR_USE_SYMVER_TRUE@ $(EGREP) -v '#(#| |$$)' $< | \ +@LIBGFOR_USE_SYMVER_TRUE@ $(PREPROCESS) -P -include config.h -include kinds.inc - > $@ || (rm -f $@ ; exit 1) +@LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@gfortran.map-sun : gfortran.ver \ @LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@ $(top_srcdir)/../contrib/make_sunver.pl \ @LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@ $(libgfortran_la_OBJECTS) $(libgfortran_la_LIBADD) @LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@ perl $(top_srcdir)/../contrib/make_sunver.pl \ -@LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@ $(srcdir)/gfortran.map \ +@LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@ gfortran.ver \ @LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@ $(libgfortran_la_OBJECTS:%.lo=.libs/%.o) \ @LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@ `echo $(libgfortran_la_LIBADD) | \ @LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@ sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \ --- libgfortran/gfortran.map.jj 2021-12-31 11:31:12.142891971 +0000 +++ libgfortran/gfortran.map 2022-01-03 19:00:02.285629389 +0000 @@ -1295,8 +1295,10 @@ GFORTRAN_8 { _gfortran_transfer_character_wide; _gfortran_transfer_character_wide_write; _gfortran_transfer_character_write; +#ifndef HAVE_GFC_REAL_17 _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; +#endif _gfortran_transfer_complex; _gfortran_transfer_complex_write; _gfortran_transfer_derived; @@ -1304,8 +1306,10 @@ GFORTRAN_8 { _gfortran_transfer_integer_write; _gfortran_transfer_logical; _gfortran_transfer_logical_write; +#ifndef HAVE_GFC_REAL_17 _gfortran_transfer_real128; _gfortran_transfer_real128_write; +#endif _gfortran_transfer_real; _gfortran_transfer_real_write; _gfortran_ttynam; @@ -1748,4 +1752,10 @@ GFORTRAN_12 { _gfortran_sproduct_c17; _gfortran_ssum_c17; _gfortran_sum_c17; +#ifdef HAVE_GFC_REAL_17 + _gfortran_transfer_complex128; + _gfortran_transfer_complex128_write; + _gfortran_transfer_real128; + _gfortran_transfer_real128_write; +#endif } GFORTRAN_10.2;