* [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
@ 2022-01-03 15:36 Jakub Jelinek
2022-01-03 16:26 ` Jakub Jelinek
2022-01-03 16:48 ` [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O Thomas Koenig
0 siblings, 2 replies; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-03 15:36 UTC (permalink / raw)
To: Thomas Koenig
Cc: Michael Meissner, Bill Schmidt, fortran, Segher Boessenkool,
Peter Bergner, David Edelsohn, gcc-patches
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: 00000000001a31d0 56 FUNC GLOBAL DEFAULT 11 _gfortran_transfer_real128@@GFORTRAN_8 [<localentry>: 8]
920: 00000000001a3210 56 FUNC GLOBAL DEFAULT 11 _gfortran_transfer_real128_write@@GFORTRAN_8 [<localentry>: 8]
487: 00000000001a3290 56 FUNC GLOBAL DEFAULT 11 _gfortran_transfer_complex128_write@@GFORTRAN_8 [<localentry>: 8]
574: 00000000001a3250 56 FUNC GLOBAL DEFAULT 11 _gfortran_transfer_complex128@@GFORTRAN_8 [<localentry>: 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 <jakub@redhat.com>
* 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.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/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/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/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)
Jakub
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
2022-01-03 15:36 [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O Jakub Jelinek
@ 2022-01-03 16:26 ` Jakub Jelinek
2022-01-03 17:03 ` Thomas Koenig
2022-01-03 16:48 ` [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O Thomas Koenig
1 sibling, 1 reply; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-03 16:26 UTC (permalink / raw)
To: Thomas Koenig, Michael Meissner, Segher Boessenkool, fortran,
Peter Bergner, Bill Schmidt, gcc-patches, David Edelsohn
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: 00000000001a31d0 56 FUNC GLOBAL DEFAULT 11 _gfortran_transfer_real128@@GFORTRAN_8 [<localentry>: 8]
> 920: 00000000001a3210 56 FUNC GLOBAL DEFAULT 11 _gfortran_transfer_real128_write@@GFORTRAN_8 [<localentry>: 8]
> 487: 00000000001a3290 56 FUNC GLOBAL DEFAULT 11 _gfortran_transfer_complex128_write@@GFORTRAN_8 [<localentry>: 8]
> 574: 00000000001a3250 56 FUNC GLOBAL DEFAULT 11 _gfortran_transfer_complex128@@GFORTRAN_8 [<localentry>: 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
2022-01-03 15:36 [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O Jakub Jelinek
2022-01-03 16:26 ` Jakub Jelinek
@ 2022-01-03 16:48 ` Thomas Koenig
1 sibling, 0 replies; 33+ messages in thread
From: Thomas Koenig @ 2022-01-03 16:48 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Segher Boessenkool, fortran, Peter Bergner, Bill Schmidt,
gcc-patches, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O
2022-01-03 16:26 ` Jakub Jelinek
@ 2022-01-03 17:03 ` Thomas Koenig
2022-01-03 20:00 ` [power-ieee128] libgfortran, fortran: " Jakub Jelinek
0 siblings, 1 reply; 33+ messages in thread
From: Thomas Koenig @ 2022-01-03 17:03 UTC (permalink / raw)
To: Jakub Jelinek, Michael Meissner, Segher Boessenkool, fortran,
Peter Bergner, Bill Schmidt, gcc-patches, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [power-ieee128] libgfortran, fortran: -mabi=ieeelongdouble I/O
2022-01-03 17:03 ` Thomas Koenig
@ 2022-01-03 20:00 ` Jakub Jelinek
2022-01-03 22:43 ` Thomas Koenig
0 siblings, 1 reply; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-03 20:00 UTC (permalink / raw)
To: Thomas Koenig
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
Bill Schmidt, gcc-patches, David Edelsohn
On Mon, Jan 03, 2022 at 06:03:41PM +0100, Thomas Koenig wrote:
> 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?
Here is an updated patch that does that (and now includes also the
gcc/fortran part, since it makes no sense to split the two).
I've run make check-fortran both normally and with
RUNTESTFLAGS='--target_board=unix\{-mabi=ieeelongdouble\}'
The former has:
FAIL: gfortran.dg/reshape_shape_2.f90 -O (internal compiler error)
FAIL: gfortran.dg/reshape_shape_2.f90 -O (test for errors, line 6)
FAIL: gfortran.dg/reshape_shape_2.f90 -O (test for excess errors)
FAIL: gfortran.dg/vector_subscript_1.f90 -O1 execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O2 execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O3 -g execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -Os execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O0 execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O1 execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O2 execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/ieee/large_2.f90 -O3 -g execution test
FAIL: gfortran.dg/ieee/large_2.f90 -Os execution test
and the latter has:
FAIL: gfortran.dg/dec_math.f90 -O0 execution test
FAIL: gfortran.dg/dec_math.f90 -O1 execution test
FAIL: gfortran.dg/dec_math.f90 -O2 execution test
FAIL: gfortran.dg/dec_math.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/dec_math.f90 -O3 -g execution test
FAIL: gfortran.dg/dec_math.f90 -Os execution test
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_pf.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_en_rd.f90 -O2 output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -O1 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_pf.f90 -O2 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_en_rd.f90 -O3 -g 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_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_en_rd.f90 -Os output pattern test
FAIL: gfortran.dg/fmt_g0_7.f08 -Os execution test
FAIL: gfortran.dg/fmt_en_rn.f90 -O0 output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -O3 -g output pattern test
FAIL: gfortran.dg/fmt_en_rn.f90 -O1 output pattern test
FAIL: gfortran.dg/fmt_pf.f90 -Os 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/intrinsic_spread_2.f90 -O0 execution test
FAIL: gfortran.dg/intrinsic_spread_2.f90 -O1 execution test
FAIL: gfortran.dg/intrinsic_spread_2.f90 -O2 execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O0 execution test
FAIL: gfortran.dg/intrinsic_spread_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O1 execution test
FAIL: gfortran.dg/intrinsic_spread_2.f90 -O3 -g execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O2 execution test
FAIL: gfortran.dg/intrinsic_spread_2.f90 -Os execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O3 -g execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90 -Os execution 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
FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O0 execution test
FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O1 execution test
FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O2 execution test
FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O3 -g execution test
FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -Os execution test
FAIL: gfortran.dg/pr47614.f -O0 (test for excess errors)
FAIL: gfortran.dg/pr47614.f -O1 (test for excess errors)
FAIL: gfortran.dg/pr47614.f -O2 (test for excess errors)
FAIL: gfortran.dg/pr47614.f -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors)
FAIL: gfortran.dg/pr47614.f -O3 -g (test for excess errors)
FAIL: gfortran.dg/pr47614.f -Os (test for excess errors)
FAIL: gfortran.dg/pr71526.f90 -O (test for excess errors)
FAIL: gfortran.dg/quad_2.f90 -O0 execution test
FAIL: gfortran.dg/quad_2.f90 -O1 execution test
FAIL: gfortran.dg/quad_2.f90 -O2 execution test
FAIL: gfortran.dg/quad_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/quad_2.f90 -O3 -g execution test
FAIL: gfortran.dg/quad_2.f90 -Os execution test
FAIL: gfortran.dg/save_6.f90 -O0 (test for excess errors)
FAIL: gfortran.dg/save_6.f90 -O1 (test for excess errors)
FAIL: gfortran.dg/save_6.f90 -O2 (test for excess errors)
FAIL: gfortran.dg/save_6.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors)
FAIL: gfortran.dg/save_6.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/save_6.f90 -Os (test for excess errors)
FAIL: gfortran.dg/reshape_shape_2.f90 -O (internal compiler error)
FAIL: gfortran.dg/reshape_shape_2.f90 -O (test for errors, line 6)
FAIL: gfortran.dg/reshape_shape_2.f90 -O (test for excess errors)
FAIL: gfortran.dg/shape_9.f90 -O (test for excess errors)
FAIL: gfortran.dg/submodule_6.f08 -O0 (test for excess errors)
FAIL: gfortran.dg/submodule_6.f08 -O1 (test for excess errors)
FAIL: gfortran.dg/submodule_6.f08 -O2 (test for excess errors)
FAIL: gfortran.dg/submodule_6.f08 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors)
FAIL: gfortran.dg/submodule_6.f08 -O3 -g (test for excess errors)
FAIL: gfortran.dg/submodule_6.f08 -Os (test for excess errors)
FAIL: gfortran.dg/vector_subscript_1.f90 -O1 execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O2 execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -O3 -g execution test
FAIL: gfortran.dg/vector_subscript_1.f90 -Os execution test
FAIL: gfortran.dg/ieee/large_1.f90 -O0 execution test
FAIL: gfortran.dg/ieee/large_1.f90 -O1 execution test
FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o link, -O0 -flto -flto-partition=none
FAIL: gfortran.dg/lto/pr46036 f_lto_pr46036_0.o-f_lto_pr46036_0.o link, -O -flto -ftree-vectorize
FAIL: gfortran.dg/lto/bind_c-5 f_lto_bind_c-5_0.o-f_lto_bind_c-5_1.o link, -O3 -flto
FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o link, -O2 -flto -flto-partition=none
FAIL: gfortran.dg/ieee/large_1.f90 -O2 execution test
FAIL: gfortran.dg/lto/pr46911 f_lto_pr46911_0.o-f_lto_pr46911_0.o link, -O2 -flto -g
FAIL: gfortran.dg/lto/bind_c-6 f_lto_bind_c-6_0.o-f_lto_bind_c-6_1.o link, -O3 -flto
FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o link, -O0 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/pr47839 f_lto_pr47839_0.o-f_lto_pr47839_1.o link, -g -flto
FAIL: gfortran.dg/ieee/large_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/lto/pr40724 f_lto_pr40724_0.o-f_lto_pr40724_1.o link, -O0 -flto -flto-partition=none
FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o link, -O2 -flto -flto-partition=1to1
FAIL: gfortran.dg/ieee/large_1.f90 -O3 -g execution test
FAIL: gfortran.dg/lto/pr40724 f_lto_pr40724_0.o-f_lto_pr40724_1.o link, -O2 -flto -flto-partition=none
FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o link, -O0 -flto
FAIL: gfortran.dg/lto/pr84645 f_lto_pr84645_0.o-f_lto_pr84645_0.o link, -flto -g0
FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o link, -O2 -flto
FAIL: gfortran.dg/lto/pr40724 f_lto_pr40724_0.o-f_lto_pr40724_1.o link, -O0 -flto -flto-partition=1to1
FAIL: gfortran.dg/ieee/large_1.f90 -Os execution test
FAIL: gfortran.dg/lto/pr87689 f_lto_pr87689_0.o-f_lto_pr87689_1.o link, -O0 -flto -flto-partition=none
FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o link, -O0 -flto -flto-partition=none
FAIL: gfortran.dg/lto/pr40724 f_lto_pr40724_0.o-f_lto_pr40724_1.o link, -O2 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/pr87689 f_lto_pr87689_0.o-f_lto_pr87689_1.o link, -O2 -flto -flto-partition=none
FAIL: gfortran.dg/lto/pr40724 f_lto_pr40724_0.o-f_lto_pr40724_1.o link, -O0 -flto
FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o link, -O2 -flto -flto-partition=none
FAIL: gfortran.dg/lto/pr87689 f_lto_pr87689_0.o-f_lto_pr87689_1.o link, -O0 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o link, -O0 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/pr40724 f_lto_pr40724_0.o-f_lto_pr40724_1.o link, -O2 -flto
FAIL: gfortran.dg/lto/pr87689 f_lto_pr87689_0.o-f_lto_pr87689_1.o link, -O2 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o link, -O0 -flto -flto-partition=none
FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o link, -O2 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/pr87689 f_lto_pr87689_0.o-f_lto_pr87689_1.o link, -O0 -flto
FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o link, -O2 -flto -flto-partition=none
FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o link, -O0 -flto
FAIL: gfortran.dg/lto/pr87689 f_lto_pr87689_0.o-f_lto_pr87689_1.o link, -O2 -flto
FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o link, -O0 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o link, -O2 -flto
FAIL: gfortran.dg/lto/pr89084 f_lto_pr89084_0.o-f_lto_pr89084_0.o link, -O0 -flto
FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o link, -O2 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/20100110-1 f_lto_20100110-1_0.o-f_lto_20100110-1_0.o link, -flto
FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o link, -O0 -flto
FAIL: gfortran.dg/lto/20100222-1 f_lto_20100222-1_0.o-f_lto_20100222-1_1.o link, -O0 -flto -flto-partition=none
FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o link, -O2 -flto
FAIL: gfortran.dg/lto/20100222-1 f_lto_20100222-1_0.o-f_lto_20100222-1_1.o link, -O2 -flto -flto-partition=none
FAIL: gfortran.dg/lto/pr41069 f_lto_pr41069_0.o-f_lto_pr41069_2.o link, -O0 -flto -flto-partition=none
FAIL: gfortran.dg/lto/20100222-1 f_lto_20100222-1_0.o-f_lto_20100222-1_1.o link, -O0 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/pr41069 f_lto_pr41069_0.o-f_lto_pr41069_2.o link, -O2 -flto -flto-partition=none
FAIL: gfortran.dg/lto/20100222-1 f_lto_20100222-1_0.o-f_lto_20100222-1_1.o link, -O2 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/pr41069 f_lto_pr41069_0.o-f_lto_pr41069_2.o link, -O0 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/20100222-1 f_lto_20100222-1_0.o-f_lto_20100222-1_1.o link, -O0 -flto
FAIL: gfortran.dg/lto/pr41069 f_lto_pr41069_0.o-f_lto_pr41069_2.o link, -O2 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/20100222-1 f_lto_20100222-1_0.o-f_lto_20100222-1_1.o link, -O2 -flto
FAIL: gfortran.dg/lto/bind-c-char f_lto_bind-c-char_0.o-f_lto_bind-c-char_0.o link, -O0 -flto
FAIL: gfortran.dg/lto/pr41069 f_lto_pr41069_0.o-f_lto_pr41069_2.o link, -O0 -flto
FAIL: gfortran.dg/lto/bind_c-1 f_lto_bind_c-1_0.o-f_lto_bind_c-1_1.o link, -O3 -flto
FAIL: gfortran.dg/lto/pr41069 f_lto_pr41069_0.o-f_lto_pr41069_2.o link, -O2 -flto
FAIL: gfortran.dg/lto/bind_c-2 f_lto_bind_c-2_0.o-f_lto_bind_c-2_1.o link, -O3 -flto
FAIL: gfortran.dg/lto/pr41521 f_lto_pr41521_0.o-f_lto_pr41521_1.o link, -g -flto -Wno-lto-type-mismatch
FAIL: gfortran.dg/lto/bind_c-2b f_lto_bind_c-2b_0.o-f_lto_bind_c-2b_1.o link, -O3 -flto
FAIL: gfortran.dg/lto/pr41521 f_lto_pr41521_0.o-f_lto_pr41521_1.o link, -g -O -flto -Wno-lto-type-mismatch
FAIL: gfortran.dg/lto/pr41576 f_lto_pr41576_0.o-f_lto_pr41576_1.o link, -O2 -flto -Werror -Wno-lto-type-mismatch
FAIL: gfortran.dg/lto/bind_c-3 f_lto_bind_c-3_0.o-f_lto_bind_c-3_1.o link, -O3 -flto
FAIL: gfortran.dg/lto/pr41764 f_lto_pr41764_0.o-f_lto_pr41764_0.o link, -O0 -flto -flto-partition=none
FAIL: gfortran.dg/lto/pr41764 f_lto_pr41764_0.o-f_lto_pr41764_0.o link, -O2 -flto -flto-partition=none
FAIL: gfortran.dg/lto/bind_c-4 f_lto_bind_c-4_0.o-f_lto_bind_c-4_1.o link, -O3 -flto
FAIL: gfortran.dg/lto/pr41764 f_lto_pr41764_0.o-f_lto_pr41764_0.o link, -O0 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/pr41764 f_lto_pr41764_0.o-f_lto_pr41764_0.o link, -O2 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/pr41764 f_lto_pr41764_0.o-f_lto_pr41764_0.o link, -O0 -flto
FAIL: gfortran.dg/lto/pr41764 f_lto_pr41764_0.o-f_lto_pr41764_0.o link, -O2 -flto
FAIL: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o link, -O0 -flto -flto-partition=none
FAIL: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o link, -O2 -flto -flto-partition=none
FAIL: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o link, -O0 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o link, -O2 -flto -flto-partition=1to1
FAIL: gfortran.dg/ieee/dec_math_1.f90 -O0 execution test
FAIL: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o link, -O0 -flto
FAIL: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o link, -O2 -flto
FAIL: gfortran.dg/ieee/dec_math_1.f90 -O1 execution test
FAIL: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o link, -O0 -flto -flto-partition=none
FAIL: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o link, -O2 -flto -flto-partition=none
FAIL: gfortran.dg/ieee/dec_math_1.f90 -O2 execution test
FAIL: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o link, -O0 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o link, -O2 -flto -flto-partition=1to1
FAIL: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o link, -O0 -flto
FAIL: gfortran.dg/ieee/dec_math_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o link, -O2 -flto
FAIL: gfortran.dg/ieee/dec_math_1.f90 -O3 -g execution test
FAIL: gfortran.dg/ieee/dec_math_1.f90 -Os execution test
FAIL: gfortran.dg/lto/20091016-1 f_lto_20091016-1_0.o-f_lto_20091016-1_0.o link, -flto -g -fPIC -r
FAIL: gfortran.dg/lto/20091016-1 f_lto_20091016-1_0.o-f_lto_20091016-1_0.o link, -O -flto -g -fPIC -r
so clearly there is still work to fix (but seems e.g. most of the lto tests
are related to the gnu attributes stuff :( ).
Ok?
2022-01-03 Jakub Jelinek <jakub@redhat.com>
gcc/fortran/
* trans-io.c (transfer_namelist_element): Use gfc_type_abi_kind,
formatting fixes.
(transfer_expr): Use gfc_type_abi_kind, use *REAL128* APIs even
for abi_kind == 17.
libgfortran/
* 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.
* Makefile.am (comma, PREPROCESS): New variables.
(gfortran.ver): New goal.
(version_arg, version_dep): Use gfortran.ver instead of
$(srcdir)/gfortran.map.
(gfortran.map-sun): Depend on and use gfortran.ver instead of
$(srcdir)/gfortran.map.
(BUILT_SOURCES): Add $(version_dep).
* Makefile.in: Regenerated.
* gfortran.map (GFORTRAN_8): Don't export
_gfortran_transfer_complex128, _gfortran_transfer_complex128_write,
_gfortran_transfer_real128 and _gfortran_transfer_real128_write if
HAVE_GFC_REAL_17 is defined.
(GFORTRAN_12): Export those here instead.
--- 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;
Jakub
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] libgfortran, fortran: -mabi=ieeelongdouble I/O
2022-01-03 20:00 ` [power-ieee128] libgfortran, fortran: " Jakub Jelinek
@ 2022-01-03 22:43 ` Thomas Koenig
2022-01-04 11:07 ` [power-ieee128] RFH: LTO broken Jakub Jelinek
0 siblings, 1 reply; 33+ messages in thread
From: Thomas Koenig @ 2022-01-03 22:43 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Segher Boessenkool, fortran, Peter Bergner, gcc-patches,
Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [power-ieee128] RFH: LTO broken
2022-01-03 22:43 ` Thomas Koenig
@ 2022-01-04 11:07 ` Jakub Jelinek
2022-01-04 13:41 ` [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix Jakub Jelinek
` (3 more replies)
0 siblings, 4 replies; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-04 11:07 UTC (permalink / raw)
To: Thomas Koenig, Michael Meissner
Cc: Segher Boessenkool, fortran, Peter Bergner, gcc-patches,
Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix
2022-01-04 11:07 ` [power-ieee128] RFH: LTO broken Jakub Jelinek
@ 2022-01-04 13:41 ` Jakub Jelinek
2022-01-04 14:35 ` Thomas Koenig
2022-01-06 2:48 ` [power-ieee128] RFH: LTO broken Michael Meissner
` (2 subsequent siblings)
3 siblings, 1 reply; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-04 13:41 UTC (permalink / raw)
To: Thomas Koenig, Michael Meissner, Segher Boessenkool, fortran,
Peter Bergner, Bill Schmidt, gcc-patches, David Edelsohn
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 <jakub@redhat.com>
* 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 +0000
+++ libgfortran/io/write_float.def 2022-01-04 13:09:51.751534884 +0000
@@ -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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix
2022-01-04 13:41 ` [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix Jakub Jelinek
@ 2022-01-04 14:35 ` Thomas Koenig
0 siblings, 0 replies; 33+ messages in thread
From: Thomas Koenig @ 2022-01-04 14:35 UTC (permalink / raw)
To: Jakub Jelinek, Michael Meissner, Segher Boessenkool, fortran,
Peter Bergner, Bill Schmidt, gcc-patches, David Edelsohn
On 04.01.22 14:41, Jakub Jelinek via Fortran wrote:
> Ok for power-ieee128?
OK.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] RFH: LTO broken
2022-01-04 11:07 ` [power-ieee128] RFH: LTO broken Jakub Jelinek
2022-01-04 13:41 ` [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix Jakub Jelinek
@ 2022-01-06 2:48 ` Michael Meissner
2022-01-06 4:17 ` Michael Meissner
2022-01-06 5:00 ` Michael Meissner
3 siblings, 0 replies; 33+ messages in thread
From: Michael Meissner @ 2022-01-06 2:48 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Thomas Koenig, Michael Meissner, Segher Boessenkool, fortran,
Peter Bergner, gcc-patches, Bill Schmidt, David Edelsohn
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: meissner@linux.ibm.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] RFH: LTO broken
2022-01-04 11:07 ` [power-ieee128] RFH: LTO broken Jakub Jelinek
2022-01-04 13:41 ` [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix Jakub Jelinek
2022-01-06 2:48 ` [power-ieee128] RFH: LTO broken Michael Meissner
@ 2022-01-06 4:17 ` Michael Meissner
2022-01-06 5:00 ` Michael Meissner
3 siblings, 0 replies; 33+ messages in thread
From: Michael Meissner @ 2022-01-06 4:17 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Thomas Koenig, Michael Meissner, Segher Boessenkool, fortran,
Peter Bergner, gcc-patches, Bill Schmidt, David Edelsohn
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)
--
2.33.1
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] RFH: LTO broken
2022-01-04 11:07 ` [power-ieee128] RFH: LTO broken Jakub Jelinek
` (2 preceding siblings ...)
2022-01-06 4:17 ` Michael Meissner
@ 2022-01-06 5:00 ` Michael Meissner
2022-01-06 20:01 ` Thomas Koenig
3 siblings, 1 reply; 33+ messages in thread
From: Michael Meissner @ 2022-01-06 5:00 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Thomas Koenig, Michael Meissner, Segher Boessenkool, fortran,
Peter Bergner, gcc-patches, Bill Schmidt, David Edelsohn
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: meissner@linux.ibm.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] RFH: LTO broken
2022-01-06 5:00 ` Michael Meissner
@ 2022-01-06 20:01 ` Thomas Koenig
2022-01-06 20:10 ` Jakub Jelinek
` (2 more replies)
0 siblings, 3 replies; 33+ messages in thread
From: Thomas Koenig @ 2022-01-06 20:01 UTC (permalink / raw)
To: Michael Meissner, Jakub Jelinek, Segher Boessenkool, fortran,
Peter Bergner, gcc-patches, Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] RFH: LTO broken
2022-01-06 20:01 ` Thomas Koenig
@ 2022-01-06 20:10 ` Jakub Jelinek
2022-01-07 9:22 ` [power-ieee128] OPEN CONV Jakub Jelinek
2022-01-07 11:29 ` [power-ieee128] RFH: LTO broken Jakub Jelinek
2 siblings, 0 replies; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-06 20:10 UTC (permalink / raw)
To: Thomas Koenig
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
gcc-patches, Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* [power-ieee128] OPEN CONV
2022-01-06 20:01 ` Thomas Koenig
2022-01-06 20:10 ` Jakub Jelinek
@ 2022-01-07 9:22 ` Jakub Jelinek
2022-01-07 10:26 ` Thomas Koenig
2022-01-07 11:29 ` [power-ieee128] RFH: LTO broken Jakub Jelinek
2 siblings, 1 reply; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-07 9:22 UTC (permalink / raw)
To: Thomas Koenig
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
gcc-patches, Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] OPEN CONV
2022-01-07 9:22 ` [power-ieee128] OPEN CONV Jakub Jelinek
@ 2022-01-07 10:26 ` Thomas Koenig
2022-01-07 19:52 ` Jakub Jelinek
0 siblings, 1 reply; 33+ messages in thread
From: Thomas Koenig @ 2022-01-07 10:26 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
gcc-patches, Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] RFH: LTO broken
2022-01-06 20:01 ` Thomas Koenig
2022-01-06 20:10 ` Jakub Jelinek
2022-01-07 9:22 ` [power-ieee128] OPEN CONV Jakub Jelinek
@ 2022-01-07 11:29 ` Jakub Jelinek
2022-01-07 13:31 ` Jakub Jelinek
2 siblings, 1 reply; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-07 11:29 UTC (permalink / raw)
To: Thomas Koenig
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
gcc-patches, Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] RFH: LTO broken
2022-01-07 11:29 ` [power-ieee128] RFH: LTO broken Jakub Jelinek
@ 2022-01-07 13:31 ` Jakub Jelinek
2022-01-07 14:25 ` Thomas Koenig
0 siblings, 1 reply; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-07 13:31 UTC (permalink / raw)
To: Thomas Koenig
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
gcc-patches, Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] RFH: LTO broken
2022-01-07 13:31 ` Jakub Jelinek
@ 2022-01-07 14:25 ` Thomas Koenig
2022-01-07 16:46 ` Jakub Jelinek
0 siblings, 1 reply; 33+ messages in thread
From: Thomas Koenig @ 2022-01-07 14:25 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
gcc-patches, Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] RFH: LTO broken
2022-01-07 14:25 ` Thomas Koenig
@ 2022-01-07 16:46 ` Jakub Jelinek
2022-01-07 21:33 ` Thomas Koenig
0 siblings, 1 reply; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-07 16:46 UTC (permalink / raw)
To: Thomas Koenig
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
gcc-patches, Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] OPEN CONV
2022-01-07 10:26 ` Thomas Koenig
@ 2022-01-07 19:52 ` Jakub Jelinek
2022-01-07 21:40 ` Thomas Koenig
0 siblings, 1 reply; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-07 19:52 UTC (permalink / raw)
To: Thomas Koenig
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
gcc-patches, Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] RFH: LTO broken
2022-01-07 16:46 ` Jakub Jelinek
@ 2022-01-07 21:33 ` Thomas Koenig
0 siblings, 0 replies; 33+ messages in thread
From: Thomas Koenig @ 2022-01-07 21:33 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
gcc-patches, Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] OPEN CONV
2022-01-07 19:52 ` Jakub Jelinek
@ 2022-01-07 21:40 ` Thomas Koenig
2022-01-07 21:48 ` Jakub Jelinek
0 siblings, 1 reply; 33+ messages in thread
From: Thomas Koenig @ 2022-01-07 21:40 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
gcc-patches, Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] OPEN CONV
2022-01-07 21:40 ` Thomas Koenig
@ 2022-01-07 21:48 ` Jakub Jelinek
2022-01-08 10:07 ` Thomas Koenig
0 siblings, 1 reply; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-07 21:48 UTC (permalink / raw)
To: Thomas Koenig
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
gcc-patches, Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] OPEN CONV
2022-01-07 21:48 ` Jakub Jelinek
@ 2022-01-08 10:07 ` Thomas Koenig
2022-01-08 11:00 ` Jakub Jelinek
0 siblings, 1 reply; 33+ messages in thread
From: Thomas Koenig @ 2022-01-08 10:07 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
gcc-patches, Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] OPEN CONV
2022-01-08 10:07 ` Thomas Koenig
@ 2022-01-08 11:00 ` Jakub Jelinek
2022-01-08 11:10 ` Jakub Jelinek
0 siblings, 1 reply; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-08 11:00 UTC (permalink / raw)
To: Thomas Koenig
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
gcc-patches, Bill Schmidt, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] OPEN CONV
2022-01-08 11:00 ` Jakub Jelinek
@ 2022-01-08 11:10 ` Jakub Jelinek
2022-01-08 14:02 ` Jakub Jelinek
0 siblings, 1 reply; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-08 11:10 UTC (permalink / raw)
To: Thomas Koenig, Michael Meissner, Segher Boessenkool, fortran,
Peter Bergner, Bill Schmidt, gcc-patches, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] OPEN CONV
2022-01-08 11:10 ` Jakub Jelinek
@ 2022-01-08 14:02 ` Jakub Jelinek
2022-01-08 14:13 ` Thomas Koenig
0 siblings, 1 reply; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-08 14:02 UTC (permalink / raw)
To: Thomas Koenig, Michael Meissner, Segher Boessenkool, fortran,
Peter Bergner, Bill Schmidt, gcc-patches, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] OPEN CONV
2022-01-08 14:02 ` Jakub Jelinek
@ 2022-01-08 14:13 ` Thomas Koenig
2022-01-08 14:18 ` Jakub Jelinek
0 siblings, 1 reply; 33+ messages in thread
From: Thomas Koenig @ 2022-01-08 14:13 UTC (permalink / raw)
To: Jakub Jelinek, Michael Meissner, Segher Boessenkool, fortran,
Peter Bergner, Bill Schmidt, gcc-patches, David Edelsohn
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...
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] OPEN CONV
2022-01-08 14:13 ` Thomas Koenig
@ 2022-01-08 14:18 ` Jakub Jelinek
2022-01-08 18:59 ` Michael Meissner
0 siblings, 1 reply; 33+ messages in thread
From: Jakub Jelinek @ 2022-01-08 14:18 UTC (permalink / raw)
To: Thomas Koenig
Cc: Michael Meissner, Segher Boessenkool, fortran, Peter Bergner,
Bill Schmidt, gcc-patches, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] OPEN CONV
2022-01-08 14:18 ` Jakub Jelinek
@ 2022-01-08 18:59 ` Michael Meissner
2022-01-08 19:15 ` David Edelsohn
0 siblings, 1 reply; 33+ messages in thread
From: Michael Meissner @ 2022-01-08 18:59 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Thomas Koenig, Michael Meissner, Segher Boessenkool, fortran,
Peter Bergner, Bill Schmidt, gcc-patches, David Edelsohn
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.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] OPEN CONV
2022-01-08 18:59 ` Michael Meissner
@ 2022-01-08 19:15 ` David Edelsohn
2022-01-08 19:37 ` Michael Meissner
0 siblings, 1 reply; 33+ messages in thread
From: David Edelsohn @ 2022-01-08 19:15 UTC (permalink / raw)
To: Michael Meissner, Jakub Jelinek, Thomas Koenig,
Segher Boessenkool, fortran, Peter Bergner, Bill Schmidt,
GCC Patches, David Edelsohn
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [power-ieee128] OPEN CONV
2022-01-08 19:15 ` David Edelsohn
@ 2022-01-08 19:37 ` Michael Meissner
0 siblings, 0 replies; 33+ messages in thread
From: Michael Meissner @ 2022-01-08 19:37 UTC (permalink / raw)
To: David Edelsohn
Cc: Michael Meissner, Jakub Jelinek, Thomas Koenig,
Segher Boessenkool, fortran, Peter Bergner, Bill Schmidt,
GCC Patches
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.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2022-01-08 19:37 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-03 15:36 [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O Jakub Jelinek
2022-01-03 16:26 ` Jakub Jelinek
2022-01-03 17:03 ` Thomas Koenig
2022-01-03 20:00 ` [power-ieee128] libgfortran, fortran: " Jakub Jelinek
2022-01-03 22:43 ` Thomas Koenig
2022-01-04 11:07 ` [power-ieee128] RFH: LTO broken Jakub Jelinek
2022-01-04 13:41 ` [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix Jakub Jelinek
2022-01-04 14:35 ` Thomas Koenig
2022-01-06 2:48 ` [power-ieee128] RFH: LTO broken Michael Meissner
2022-01-06 4:17 ` Michael Meissner
2022-01-06 5:00 ` Michael Meissner
2022-01-06 20:01 ` Thomas Koenig
2022-01-06 20:10 ` Jakub Jelinek
2022-01-07 9:22 ` [power-ieee128] OPEN CONV Jakub Jelinek
2022-01-07 10:26 ` Thomas Koenig
2022-01-07 19:52 ` Jakub Jelinek
2022-01-07 21:40 ` Thomas Koenig
2022-01-07 21:48 ` Jakub Jelinek
2022-01-08 10:07 ` Thomas Koenig
2022-01-08 11:00 ` Jakub Jelinek
2022-01-08 11:10 ` Jakub Jelinek
2022-01-08 14:02 ` Jakub Jelinek
2022-01-08 14:13 ` Thomas Koenig
2022-01-08 14:18 ` Jakub Jelinek
2022-01-08 18:59 ` Michael Meissner
2022-01-08 19:15 ` David Edelsohn
2022-01-08 19:37 ` Michael Meissner
2022-01-07 11:29 ` [power-ieee128] RFH: LTO broken Jakub Jelinek
2022-01-07 13:31 ` Jakub Jelinek
2022-01-07 14:25 ` Thomas Koenig
2022-01-07 16:46 ` Jakub Jelinek
2022-01-07 21:33 ` Thomas Koenig
2022-01-03 16:48 ` [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O Thomas Koenig
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).