[power-ieee128] libgfortran: -mabi=ieeelongdouble I/O

[power-ieee128] libgfortran: -mabi=ieeelongdouble I/O

[Jakub Jelinek]

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

Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O

[Jakub Jelinek]

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

Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O

[Thomas Koenig]

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

[power-ieee128] libgfortran, fortran: -mabi=ieeelongdouble I/O

[Jakub Jelinek]

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

Re: [power-ieee128] libgfortran, fortran: -mabi=ieeelongdouble I/O

[Thomas Koenig]

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

[power-ieee128] RFH: LTO broken

[Jakub Jelinek]

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

[power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix

[Jakub Jelinek]

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

Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O fix

[Thomas Koenig]

On 04.01.22 14:41, Jakub Jelinek via Fortran wrote:
> Ok for power-ieee128?

OK.

Re: [power-ieee128] RFH: LTO broken

[Michael Meissner]

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

Re: [power-ieee128] RFH: LTO broken

[Michael Meissner]

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

Re: [power-ieee128] RFH: LTO broken

[Michael Meissner]

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

Re: [power-ieee128] RFH: LTO broken

[Thomas Koenig]

On 06.01.22 06:00, Michael Meissner via Fortran wrote:
> I pushed the patch to the branch.

Test results are looking quite good right now.

What is still missing is the conversion for unformatted I/O, both
ways.  I'll start doing some stuff on it. Just one question:
What are functions that I can use to convert from IBM long double
to IEEE and long double and vice versa?  It was in an e-mail somewhere,
but I cannot find it at the moment.

Best regards

	Thomas

Re: [power-ieee128] RFH: LTO broken

[Jakub Jelinek]

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

[power-ieee128] OPEN CONV

[Jakub Jelinek]

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

Re: [power-ieee128] OPEN CONV

[Thomas Koenig]

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

Re: [power-ieee128] OPEN CONV

[Jakub Jelinek]

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

Re: [power-ieee128] OPEN CONV

[Thomas Koenig]

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

Re: [power-ieee128] OPEN CONV

[Jakub Jelinek]

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

Re: [power-ieee128] OPEN CONV

[Thomas Koenig]

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

Re: [power-ieee128] OPEN CONV

[Jakub Jelinek]

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

Re: [power-ieee128] OPEN CONV

[Jakub Jelinek]

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

Re: [power-ieee128] OPEN CONV

[Jakub Jelinek]

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

Re: [power-ieee128] OPEN CONV

[Thomas Koenig]

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...

Re: [power-ieee128] OPEN CONV

[Jakub Jelinek]

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

Re: [power-ieee128] OPEN CONV

[Michael Meissner]

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

Re: [power-ieee128] OPEN CONV

[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

Re: [power-ieee128] OPEN CONV

[Michael Meissner]

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

Re: [power-ieee128] RFH: LTO broken

[Jakub Jelinek]

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

Re: [power-ieee128] RFH: LTO broken

[Jakub Jelinek]

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

Re: [power-ieee128] RFH: LTO broken

[Thomas Koenig]

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

Re: [power-ieee128] RFH: LTO broken

[Jakub Jelinek]

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

Re: [power-ieee128] RFH: LTO broken

[Thomas Koenig]

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

Re: [power-ieee128] libgfortran: -mabi=ieeelongdouble I/O

[Thomas Koenig]

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