Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix
On 04.01.22 14:41, Jakub Jelinek via Fortran wrote: Ok for power-ieee128? OK.
[power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix
Hi! The following patch fixes: FAIL: gfortran.dg/fmt_en.f90 -O0 output pattern test FAIL: gfortran.dg/fmt_en.f90 -O1 output pattern test FAIL: gfortran.dg/fmt_en.f90 -O2 output pattern test FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test FAIL: gfortran.dg/fmt_en.f90 -O3 -g output pattern test FAIL: gfortran.dg/fmt_en.f90 -Os output pattern test FAIL: gfortran.dg/fmt_en_rd.f90 -O0 output pattern test FAIL: gfortran.dg/fmt_en_rd.f90 -O1 output pattern test FAIL: gfortran.dg/fmt_en_rd.f90 -O2 output pattern test FAIL: gfortran.dg/fmt_en_rd.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test FAIL: gfortran.dg/fmt_en_rd.f90 -O3 -g output pattern test FAIL: gfortran.dg/fmt_en_rd.f90 -Os output pattern test FAIL: gfortran.dg/fmt_en_rn.f90 -O0 output pattern test FAIL: gfortran.dg/fmt_en_rn.f90 -O1 output pattern test FAIL: gfortran.dg/fmt_en_rn.f90 -O2 output pattern test FAIL: gfortran.dg/fmt_en_rn.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test FAIL: gfortran.dg/fmt_en_rn.f90 -O3 -g output pattern test FAIL: gfortran.dg/fmt_en_rn.f90 -Os output pattern test FAIL: gfortran.dg/fmt_en_ru.f90 -O0 output pattern test FAIL: gfortran.dg/fmt_en_ru.f90 -O1 output pattern test FAIL: gfortran.dg/fmt_en_ru.f90 -O2 output pattern test FAIL: gfortran.dg/fmt_en_ru.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test FAIL: gfortran.dg/fmt_en_ru.f90 -O3 -g output pattern test FAIL: gfortran.dg/fmt_en_ru.f90 -Os output pattern test FAIL: gfortran.dg/fmt_en_rz.f90 -O0 output pattern test FAIL: gfortran.dg/fmt_en_rz.f90 -O1 output pattern test FAIL: gfortran.dg/fmt_en_rz.f90 -O2 output pattern test FAIL: gfortran.dg/fmt_en_rz.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test FAIL: gfortran.dg/fmt_en_rz.f90 -O3 -g output pattern test FAIL: gfortran.dg/fmt_en_rz.f90 -Os output pattern test FAIL: gfortran.dg/fmt_g0_7.f08 -O0 execution test FAIL: gfortran.dg/fmt_g0_7.f08 -O1 execution test FAIL: gfortran.dg/fmt_g0_7.f08 -O2 execution test FAIL: gfortran.dg/fmt_g0_7.f08 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/fmt_g0_7.f08 -O3 -g execution test FAIL: gfortran.dg/fmt_g0_7.f08 -Os execution test FAIL: gfortran.dg/fmt_pf.f90 -O0 output pattern test FAIL: gfortran.dg/fmt_pf.f90 -O1 output pattern test FAIL: gfortran.dg/fmt_pf.f90 -O2 output pattern test FAIL: gfortran.dg/fmt_pf.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test FAIL: gfortran.dg/fmt_pf.f90 -O3 -g output pattern test FAIL: gfortran.dg/fmt_pf.f90 -Os output pattern test FAIL: gfortran.dg/large_real_kind_1.f90 -O0 execution test FAIL: gfortran.dg/large_real_kind_1.f90 -O1 execution test FAIL: gfortran.dg/large_real_kind_1.f90 -O2 execution test FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -g execution test FAIL: gfortran.dg/large_real_kind_1.f90 -Os execution test Ok for power-ieee128? 2022-01-04 Jakub Jelinek * io/write_float.def (CALCULATE_EXP): If HAVE_GFC_REAL_17, also use CALCULATE_EXP(17). (determine_en_precision): Use 17 instead of 16 as first EN_PREC argument for kind 17. (get_float_string): Use 17 instead of 16 as first FORMAT_FLOAT argument for kind 17. --- libgfortran/io/write_float.def.jj 2022-01-04 10:27:56.528323600 + +++ libgfortran/io/write_float.def 2022-01-04 13:09:51.751534884 + @@ -799,6 +799,10 @@ CALCULATE_EXP(10) #ifdef HAVE_GFC_REAL_16 CALCULATE_EXP(16) #endif + +#ifdef HAVE_GFC_REAL_17 +CALCULATE_EXP(17) +#endif #undef CALCULATE_EXP @@ -942,7 +946,7 @@ determine_en_precision (st_parameter_dt #endif #ifdef HAVE_GFC_REAL_17 case 17: - EN_PREC(16,Q) + EN_PREC(17,Q) #endif break; default: @@ -1150,7 +1154,7 @@ get_float_string (st_parameter_dt *dtp, #endif #ifdef HAVE_GFC_REAL_17 case 17: - FORMAT_FLOAT(16,Q) + FORMAT_FLOAT(17,Q) break; #endif default: Jakub
Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
On 03.01.22 17:26, Jakub Jelinek wrote: so we could similarly have something like: #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; #endif ... #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_real128; _gfortran_transfer_real128_write; #endif ... #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16 _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; _gfortran_transfer_real128; _gfortran_transfer_real128_write; #endif That would also work for me. or make that dependent on HAVE_GFC_REAL_17 or whatever else (with suitable includes that only define macros and not actual C code). With my most recent commit, HAVE_GFC_REAL_17 can now be found in kinds.inc if all of the macros above are defined, that should be suitable. I found that __powerpc64__ is not defined when compiling *.F90 files (which is why I added them by hand). Not sure how the preprocessor is invoked on gfortran.map, but if things don't work, this could be related :-) So, it's OK either way with me. What do others think? Best regards Thomas
Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
Hi Jakub,
So, either we'd need to add e.g. preprocessing support for gfortran.map
or some other way how to make certain symbols appear conditionally at
different symbol versions, or another option would be to choose different
symbol names for those for the powerpc64le-linux cases
(e.g._gfortran_transfer_{real,complex}ieee128{,_write}).
Any preferences?
My personal preference would be the ieee128 variant, it would be cleaner
that way, but I have no strong opinion either way.
So, that variant is OK from my side, but maybe you could wait for
a day or so for anybody else to chime in.
Best regards
Thomas
Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
On Mon, Jan 03, 2022 at 04:36:21PM +0100, Jakub Jelinek via Gcc-patches wrote: > The following patch adds the library side of -mabi=ieeelongdouble > I/O support. > > There is one issue to be resolved though, for the sake of libgfortran.a > built on an older powerpc64le-linux system (glibc older than 2.32) and > then deployed on glibc 2.32 or later, I believe we want to use > _gfortran_transfer_real128_write etc. APIs so that we force in libquadmath > in that case. The following patch does that, but unfortunately it means > that right now those >512: 001a31d056 FUNCGLOBAL DEFAULT 11 > _gfortran_transfer_real128@@GFORTRAN_8 [: 8] >920: 001a321056 FUNCGLOBAL DEFAULT 11 > _gfortran_transfer_real128_write@@GFORTRAN_8 [: 8] >487: 001a329056 FUNCGLOBAL DEFAULT 11 > _gfortran_transfer_complex128_write@@GFORTRAN_8[: 8] >574: 001a325056 FUNCGLOBAL DEFAULT 11 > _gfortran_transfer_complex128@@GFORTRAN_8 [: 8] > symbols. But those symbols weren't exported on powerpc64le-linux in > GCC 8, 9, 10 or 11, so they shouldn't be exported @@GFORTRAN_8, but > @@GFORTRAN_12. > > So, either we'd need to add e.g. preprocessing support for gfortran.map Note, an example of preprocessed version file is e.g. libgomp, in the Makefile it does: # -Wc is only a libtool option. comma = , PREPROCESS = $(subst -Wc$(comma), , $(COMPILE)) -E libgomp.ver: $(top_srcdir)/libgomp.map $(EGREP) -v '#(#| |$$)' $< | \ $(PREPROCESS) -P -include config.h - > $@ || (rm -f $@ ; exit 1) and in libgomp.map it has both: #ifdef HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT # If the assembler used lacks the .symver directive or the linker # doesn't support GNU symbol versioning, we have the same symbol in # two versions, which Sun ld chokes on. omp_init_lock; ... #endif so we could similarly have something like: #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; #endif ... #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16) _gfortran_transfer_real128; _gfortran_transfer_real128_write; #endif ... #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ && __SIZEOF_LONG_DOUBLE__ == 16 _gfortran_transfer_complex128; _gfortran_transfer_complex128_write; _gfortran_transfer_real128; _gfortran_transfer_real128_write; #endif or make that dependent on HAVE_GFC_REAL_17 or whatever else (with suitable includes that only define macros and not actual C code). Jakub
[power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
Hi!
The following patch adds the library side of -mabi=ieeelongdouble
I/O support.
There is one issue to be resolved though, for the sake of libgfortran.a
built on an older powerpc64le-linux system (glibc older than 2.32) and
then deployed on glibc 2.32 or later, I believe we want to use
_gfortran_transfer_real128_write etc. APIs so that we force in libquadmath
in that case. The following patch does that, but unfortunately it means
that right now those
512: 001a31d056 FUNCGLOBAL DEFAULT 11
_gfortran_transfer_real128@@GFORTRAN_8 [: 8]
920: 001a321056 FUNCGLOBAL DEFAULT 11
_gfortran_transfer_real128_write@@GFORTRAN_8 [: 8]
487: 001a329056 FUNCGLOBAL DEFAULT 11
_gfortran_transfer_complex128_write@@GFORTRAN_8 [: 8]
574: 001a325056 FUNCGLOBAL DEFAULT 11
_gfortran_transfer_complex128@@GFORTRAN_8[: 8]
symbols. But those symbols weren't exported on powerpc64le-linux in
GCC 8, 9, 10 or 11, so they shouldn't be exported @@GFORTRAN_8, but
@@GFORTRAN_12.
So, either we'd need to add e.g. preprocessing support for gfortran.map
or some other way how to make certain symbols appear conditionally at
different symbol versions, or another option would be to choose different
symbol names for those for the powerpc64le-linux cases
(e.g. _gfortran_transfer_{real,complex}ieee128{,_write}).
Any preferences?
2022-01-03 Jakub Jelinek
* libgfortran.h (__acoshieee128, __acosieee128, __asinhieee128,
__asinieee128, __atan2ieee128, __atanhieee128, __atanieee128,
__coshieee128, __cosieee128, __erfieee128, __expieee128,
__fabsieee128, __jnieee128, __log10ieee128, __logieee128,
__powieee128, __sinhieee128, __sinieee128, __sqrtieee128,
__tanhieee128, __tanieee128, __ynieee128): Formatting fixes.
(__strtoieee128, __snprintfieee128): Declare.
* io/io.h (default_width_for_float, default_precision_for_float):
Handle kind == 17.
* io/size_from_kind.c (size_from_real_kind, size_from_complex_kind):
Likewise.
* io/read.c (set_integer, si_max, convert_real, convert_infnan,
read_f): Likewise.
* io/write.c (extract_uint, size_from_kind, set_fnode_default):
Likewise.
* io/write_float.def (DTOA2Q, FDTOA2Q): Define for HAVE_GFC_REAL_17.
(determine_en_precision, get_float_string): Handle kind == 17.
* io/transfer128.c: Use also for HAVE_GFC_REAL_17, but don't drag in
libquadmath if POWER_IEEE128.
--- libgfortran/libgfortran.h.jj2021-12-31 11:45:06.121158716 +
+++ libgfortran/libgfortran.h 2022-01-03 14:32:45.063730903 +
@@ -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 (__
