[RFC] User-visible changes for powerpc64-le-linux ABI changes

[RFC] User-visible changes for powerpc64-le-linux ABI changes

[Thomas Koenig]

Hi,

I have put together a summary of what users should see
as a change.  I've made this a diff against the current
documentation.  This is an RFC, please feel free to
suggest any changes.

I have put in a few remarks among the diff.

If there is general agreement that this is the best way forward, then
we can proceed along those lines.

Best regards

	Thomas

iff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index a54153b0951..89319a7836f 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -604,7 +604,7 @@ Malformed environment variables are silently ignored.
  * GFORTRAN_SHOW_LOCUS::  Show location for runtime errors
  * GFORTRAN_OPTIONAL_PLUS:: Print leading + where permitted
  * GFORTRAN_LIST_SEPARATOR::  Separator for list output
-* GFORTRAN_CONVERT_UNIT::  Set endianness for unformatted I/O
+* GFORTRAN_CONVERT_UNIT::  Set conversion for unformatted I/O
  * GFORTRAN_ERROR_BACKTRACE:: Show backtrace on run-time errors
  * GFORTRAN_FORMATTED_BUFFER_SIZE:: Buffer size for formatted files
  * GFORTRAN_UNFORMATTED_BUFFER_SIZE:: Buffer size for unformatted files
@@ -701,18 +701,25 @@ when @command{a.out} is the compiled Fortran 
program that you want to run.
  Default is a single space.

  @node GFORTRAN_CONVERT_UNIT
-@section @env{GFORTRAN_CONVERT_UNIT}---Set endianness for unformatted I/O
+@section @env{GFORTRAN_CONVERT_UNIT}---Set conversion for unformatted I/O

  By setting the @env{GFORTRAN_CONVERT_UNIT} variable, it is possible
  to change the representation of data for unformatted files.
-The syntax for the @env{GFORTRAN_CONVERT_UNIT} variable is:
+The syntax for the @env{GFORTRAN_CONVERT_UNIT} variable for
+systems is:
  @smallexample
  GFORTRAN_CONVERT_UNIT: mode | mode ';' exception | exception ;
-mode: 'native' | 'swap' | 'big_endian' | 'little_endian' ;
+mode: 'native' | 'swap' | 'big_endian' | 'little_endian' | power_mode;
+power_mode: 'r16_ieee' | 'native+r16_ieee' | 'swap+r16_ieee'
+            | 'big_endian+r16_ieee' | 'little_endian+r16_ieee'
+            | 'r16_ibm' | 'native+r16_ibm' | 'swap+r16_ibm'
+            | 'big_endian+r16_ibm' | 'little_endian+r16_ibm'
  exception: mode ':' unit_list | unit_list ;
-unit_list: unit_spec | unit_list unit_spec ;
+unit_list: unit_spec | unit_list ',' unit_spec ;
  unit_spec: INTEGER | INTEGER '-' INTEGER ;
  @end smallexample
+where @code{power_mode} is valid on POWER systems only.
+
  The variable consists of an optional default mode, followed by
  a list of optional exceptions, which are separated by semicolons
  from the preceding default and each other.  Each exception consists
@@ -726,6 +733,44 @@ the modes are the same as for the @code{CONVERT} 
specifier:
  for unformatted files.
  @item @code{BIG_ENDIAN} Use the big-endian format for unformatted files.
  @end itemize
+
+For POWER systems, additionally the options
+@itemize @w{}
+@item @code{R16_IEEE} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{NATIVE+R16_IEEE} Use IEEE 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{SWAP+R16_IEEE} Swap between little- and big-endian,
+use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{LITTLE_ENDIAN+R16_IEEE} Use the little-endian format for
+unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{BIG_ENDIAN+R16_IEEE} Use the big-endian format for
+unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{R16_IEEE} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{NATIVE+R16_IEEE} Use IEEE 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{SWAP+R16_IEEE} Swap between little- and big-endian,
+use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{LITTLE_ENDIAN+R16_IEEE} Use the little-endian format for
+unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{BIG_ENDIAN+R16_IEEE} Use the big-endian format for
+unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{R16_IBM} Use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{NATIVE+R16_IBM} Use IBM 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{SWAP+R16_IBM} Swap between little- and big-endian,
+use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{LITTLE_ENDIAN+R16_IBM} Use the little-endian format for
+unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{BIG_ENDIAN+R16_IBM} Use the big-endian format for
+unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{R16_IBM} Use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{NATIVE+R16_IBM} Use IBM 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{SWAP+R16_IBM} Swap between little- and big-endian,
+use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{LITTLE_ENDIAN+R16_IBM} Use the little-endian format for
+unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{BIG_ENDIAN+R16_IBM} Use the big-endian format for
+unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
+@end itemize
+are valid.
+

Remark: Not really sure if this is the most elegant way of putting
it, suggestions for improved wording welcome (but can be done later,
as long as the specification is not changed).


  A missing mode for an exception is taken to mean @code{BIG_ENDIAN}.
  Examples of values for @env{GFORTRAN_CONVERT_UNIT} are:
  @itemize @w{}
@@ -2141,6 +2186,44 @@ for unformatted files.
  unformatted files.
  @end itemize

+For POWER systems, there is also the possibility to convert between
+the ``IBM'' and the ``IEEE'' format for @code{REAL(KIND=16)}.  Additional
+valid values for @code{CONVERT} are:
+@itemize @w{}
+@item @code{CONVERT='R16_IEEE'} Use IEEE 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{CONVERT='NATIVE+R16_IEEE'} Use IEEE 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{CONVERT='SWAP+R16_IEEE'} Swap between little- and big-endian,
+use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{CONVERT='LITTLE_ENDIAN+R16_IEEE'} Use the little-endian 
format for
+unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{CONVERT='BIG_ENDIAN+R16_IEEE'} Use the big-endian format for
+unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{CONVERT='R16_IEEE'} Use IEEE 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{CONVERT='NATIVE+R16_IEEE'} Use IEEE 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{CONVERT='SWAP+R16_IEEE'} Swap between little- and big-endian,
+use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{CONVERT='LITTLE_ENDIAN+R16_IEEE'} Use the little-endian 
format for
+unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{CONVERT='BIG_ENDIAN+R16_IEEE'} Use the big-endian format for
+unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{CONVERT='R16_IBM'} Use IBM 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{CONVERT='NATIVE+R16_IBM'} Use IBM 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{CONVERT='SWAP+R16_IBM'} Swap between little- and big-endian,
+use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{CONVERT='LITTLE_ENDIAN+R16_IBM'} Use the little-endian 
format for
+unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{CONVERT='BIG_ENDIAN+R16_IBM'} Use the big-endian format for
+unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{CONVERT='R16_IBM'} Use IBM 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{CONVERT='NATIVE+R16_IBM'} Use IBM 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{CONVERT='SWAP+R16_IBM'} Swap between little- and big-endian,
+use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{CONVERT='LITTLE_ENDIAN+R16_IBM'} Use the little-endian 
format for
+unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{CONVERT='BIG_ENDIAN+R16_IBM'} Use the big-endian format for
+unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
+@end itemize
+
  Using the option could look like this:
  @smallexample
    open(file='big.dat',form='unformatted',access='sequential', &
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 0fb7e1add7e..82ca3eac522 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -127,7 +127,8 @@ by type.  Explanations are in the following sections.
  -fimplicit-none -finteger-4-integer-8 -fmax-identifier-length @gol
  -fmodule-private -ffixed-form -fno-range-check -fopenacc -fopenmp @gol
  -freal-4-real-10 -freal-4-real-16 -freal-4-real-8 -freal-8-real-10 @gol
--freal-8-real-16 -freal-8-real-4 -std=@var{std} -ftest-forall-temp
+-freal-8-real-16 -freal-8-real-4 -std=@var{std} -ftest-forall-temp @gol
+-freal-16=ibm -freal-16=ieee
  }


Remark: I am not sure if there will be an equivalent flag for C or C++.
If there is, we could make this an alias, or use the C/C++ flag instead
of a Fortran-specific one.

We will have to have some way of compiling the REAL(KIND=16) library
functions twice with the appropriate flag and also some additional
name mangling, for which a little bit of m4 hackery will be needed.


  @item Preprocessing Options
@@ -539,6 +540,34 @@ when passing a value to the @code{kind=} dummy 
argument.  Inspection of the
  intermediate representation of the translated Fortran code, produced by
  @option{-fdump-fortran-original} or @option{-fdump-tree-original}, is 
suggested.

+@item -freal-16=ibm
+@item -freal-16=ieee
+@opindex @code{freal-16=ibm}
+@opindex @code{freal-16=ieee}
+These options are only available on POWER systems.  They select
+between the two possible formats available on POWER systems for
+@code{REAL(KIND=16)} variables.  The ``IBM'' format consists of two
+doubles (also known as @code{double double} or @code{__ibm128} and
+the ``IEEE'' format of a 16-byte number in the format specified by
+``IEEE 754'' (also known as @code{__ieee128}).
+
+The default is @code{-freal-16=ibm}.
+
+These options change the ABI of the code.  Code containing
+@code{REAL=16} values compiled with one of these options is
+@emph{incompatible} with code compiled with the other option.  The
+compiler might or might not detect such incompatibilites, or they
+might lead to silent data corruption.
+
+In gfortran 11 or earlier, only the ``IBM'' format of
+@code{REAL(KIND=16)} was supported.
+
+The @ref{CONVERT specifier} can be used to read or write data
+unformatted data containing @code{REAL(KIND=16)} in either the ``IBM''
+or ``IEEE'' format, as can the @ref{GFORTRAN_CONVERT_UNIT} environment
+variable and the @option{-fconvert} option.
+
+
  @item -std=@var{std}
  @opindex @code{std=}@var{std} option
  Specify the standard to which the program is expected to conform,
@@ -1404,6 +1433,42 @@ swap between big- and little-endian; 
@samp{big-endian}, use big-endian
  representation for unformatted files; @samp{little-endian}, use 
little-endian
  representation for unformatted files.

+For POWER systems, there are additional options which specify if the
+``IEEE'' or the ``IBM'' format are used for @code{REAL(KIND=16)} variables
+for unformatted I/O.  Valid are:
+@item @code{r16-ieee} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{native+r16-ieee} Use IEEE 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{swap+r16-ieee} Swap between little- and big-endian,
+use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{little-endian+r16-ieee} Use the little-endian format for
+unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{big-endian+r16-ieee} Use the big-endian format for
+unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{r16-ieee} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{native+r16-ieee} Use IEEE 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{swap+r16-ieee} Swap between little- and big-endian,
+use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{little-endian+r16-ieee} Use the little-endian format for
+unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{big-endian+r16-ieee} Use the big-endian format for
+unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{r16-ibm} Use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{native+r16-ibm} Use IBM 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{swap+r16-ibm} Swap between little- and big-endian,
+use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{little-endian+r16-ibm} Use the little-endian format for
+unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{big-endian+r16-ibm} Use the big-endian format for
+unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{r16-ibm} Use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{native+r16-ibm} Use IBM 128-bit format for 
@code{REAL(KIND=16)}.
+@item @code{swap+r16-ibm} Swap between little- and big-endian,
+use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{little-endian+r16-ibm} Use the little-endian format for
+unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
+@item @code{big-endian+r16-ibm} Use the big-endian format for
+unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
+
  @emph{This option has an effect only when used in the main program.
  The @code{CONVERT} specifier and the GFORTRAN_CONVERT_UNIT environment
  variable override the default specified by @option{-fconvert}.}

Remark: Not sure if the '+' sign is a good idea in an option, or if we
should use something else there.

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Bill Schmidt]

Hi Thomas,

To me this looks excellent.  If you feel that support for both forms is achievable,
that's certainly superior.  We had previously been concerned about whether the
necessary name mangling support would be possible, but it sounds like you aren't
overly worried about that.

I'll let Mike weigh in about using the same options as are present for C/C++, which
I think should be the right approach, but I know I don't know all the subtleties.
That would also help determine whether -freal-16=ibm is the right default.  I think
it probably is, but I'll let those more familiar with the details weigh in.

Thanks again!
Bill

On 10/31/21 9:43 AM, Thomas Koenig wrote:
> Hi,
>
> I have put together a summary of what users should see
> as a change.  I've made this a diff against the current
> documentation.  This is an RFC, please feel free to
> suggest any changes.
>
> I have put in a few remarks among the diff.
>
> If there is general agreement that this is the best way forward, then
> we can proceed along those lines.
>
> Best regards
>
>     Thomas
>
> iff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
> index a54153b0951..89319a7836f 100644
> --- a/gcc/fortran/gfortran.texi
> +++ b/gcc/fortran/gfortran.texi
> @@ -604,7 +604,7 @@ Malformed environment variables are silently ignored.
>  * GFORTRAN_SHOW_LOCUS::  Show location for runtime errors
>  * GFORTRAN_OPTIONAL_PLUS:: Print leading + where permitted
>  * GFORTRAN_LIST_SEPARATOR::  Separator for list output
> -* GFORTRAN_CONVERT_UNIT::  Set endianness for unformatted I/O
> +* GFORTRAN_CONVERT_UNIT::  Set conversion for unformatted I/O
>  * GFORTRAN_ERROR_BACKTRACE:: Show backtrace on run-time errors
>  * GFORTRAN_FORMATTED_BUFFER_SIZE:: Buffer size for formatted files
>  * GFORTRAN_UNFORMATTED_BUFFER_SIZE:: Buffer size for unformatted files
> @@ -701,18 +701,25 @@ when @command{a.out} is the compiled Fortran program that you want to run.
>  Default is a single space.
>
>  @node GFORTRAN_CONVERT_UNIT
> -@section @env{GFORTRAN_CONVERT_UNIT}---Set endianness for unformatted I/O
> +@section @env{GFORTRAN_CONVERT_UNIT}---Set conversion for unformatted I/O
>
>  By setting the @env{GFORTRAN_CONVERT_UNIT} variable, it is possible
>  to change the representation of data for unformatted files.
> -The syntax for the @env{GFORTRAN_CONVERT_UNIT} variable is:
> +The syntax for the @env{GFORTRAN_CONVERT_UNIT} variable for
> +systems is:
>  @smallexample
>  GFORTRAN_CONVERT_UNIT: mode | mode ';' exception | exception ;
> -mode: 'native' | 'swap' | 'big_endian' | 'little_endian' ;
> +mode: 'native' | 'swap' | 'big_endian' | 'little_endian' | power_mode;
> +power_mode: 'r16_ieee' | 'native+r16_ieee' | 'swap+r16_ieee'
> +            | 'big_endian+r16_ieee' | 'little_endian+r16_ieee'
> +            | 'r16_ibm' | 'native+r16_ibm' | 'swap+r16_ibm'
> +            | 'big_endian+r16_ibm' | 'little_endian+r16_ibm'
>  exception: mode ':' unit_list | unit_list ;
> -unit_list: unit_spec | unit_list unit_spec ;
> +unit_list: unit_spec | unit_list ',' unit_spec ;
>  unit_spec: INTEGER | INTEGER '-' INTEGER ;
>  @end smallexample
> +where @code{power_mode} is valid on POWER systems only.
> +
>  The variable consists of an optional default mode, followed by
>  a list of optional exceptions, which are separated by semicolons
>  from the preceding default and each other.  Each exception consists
> @@ -726,6 +733,44 @@ the modes are the same as for the @code{CONVERT} specifier:
>  for unformatted files.
>  @item @code{BIG_ENDIAN} Use the big-endian format for unformatted files.
>  @end itemize
> +
> +For POWER systems, additionally the options
> +@itemize @w{}
> +@item @code{R16_IEEE} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{NATIVE+R16_IEEE} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{SWAP+R16_IEEE} Swap between little- and big-endian,
> +use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{LITTLE_ENDIAN+R16_IEEE} Use the little-endian format for
> +unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{BIG_ENDIAN+R16_IEEE} Use the big-endian format for
> +unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{R16_IEEE} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{NATIVE+R16_IEEE} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{SWAP+R16_IEEE} Swap between little- and big-endian,
> +use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{LITTLE_ENDIAN+R16_IEEE} Use the little-endian format for
> +unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{BIG_ENDIAN+R16_IEEE} Use the big-endian format for
> +unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{R16_IBM} Use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{NATIVE+R16_IBM} Use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{SWAP+R16_IBM} Swap between little- and big-endian,
> +use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{LITTLE_ENDIAN+R16_IBM} Use the little-endian format for
> +unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{BIG_ENDIAN+R16_IBM} Use the big-endian format for
> +unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{R16_IBM} Use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{NATIVE+R16_IBM} Use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{SWAP+R16_IBM} Swap between little- and big-endian,
> +use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{LITTLE_ENDIAN+R16_IBM} Use the little-endian format for
> +unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{BIG_ENDIAN+R16_IBM} Use the big-endian format for
> +unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@end itemize
> +are valid.
> +
>
> Remark: Not really sure if this is the most elegant way of putting
> it, suggestions for improved wording welcome (but can be done later,
> as long as the specification is not changed).
>
>
>  A missing mode for an exception is taken to mean @code{BIG_ENDIAN}.
>  Examples of values for @env{GFORTRAN_CONVERT_UNIT} are:
>  @itemize @w{}
> @@ -2141,6 +2186,44 @@ for unformatted files.
>  unformatted files.
>  @end itemize
>
> +For POWER systems, there is also the possibility to convert between
> +the ``IBM'' and the ``IEEE'' format for @code{REAL(KIND=16)}.  Additional
> +valid values for @code{CONVERT} are:
> +@itemize @w{}
> +@item @code{CONVERT='R16_IEEE'} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='NATIVE+R16_IEEE'} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='SWAP+R16_IEEE'} Swap between little- and big-endian,
> +use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='LITTLE_ENDIAN+R16_IEEE'} Use the little-endian format for
> +unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='BIG_ENDIAN+R16_IEEE'} Use the big-endian format for
> +unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='R16_IEEE'} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='NATIVE+R16_IEEE'} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='SWAP+R16_IEEE'} Swap between little- and big-endian,
> +use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='LITTLE_ENDIAN+R16_IEEE'} Use the little-endian format for
> +unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='BIG_ENDIAN+R16_IEEE'} Use the big-endian format for
> +unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='R16_IBM'} Use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='NATIVE+R16_IBM'} Use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='SWAP+R16_IBM'} Swap between little- and big-endian,
> +use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='LITTLE_ENDIAN+R16_IBM'} Use the little-endian format for
> +unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='BIG_ENDIAN+R16_IBM'} Use the big-endian format for
> +unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='R16_IBM'} Use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='NATIVE+R16_IBM'} Use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='SWAP+R16_IBM'} Swap between little- and big-endian,
> +use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='LITTLE_ENDIAN+R16_IBM'} Use the little-endian format for
> +unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{CONVERT='BIG_ENDIAN+R16_IBM'} Use the big-endian format for
> +unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@end itemize
> +
>  Using the option could look like this:
>  @smallexample
>    open(file='big.dat',form='unformatted',access='sequential', &
> diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
> index 0fb7e1add7e..82ca3eac522 100644
> --- a/gcc/fortran/invoke.texi
> +++ b/gcc/fortran/invoke.texi
> @@ -127,7 +127,8 @@ by type.  Explanations are in the following sections.
>  -fimplicit-none -finteger-4-integer-8 -fmax-identifier-length @gol
>  -fmodule-private -ffixed-form -fno-range-check -fopenacc -fopenmp @gol
>  -freal-4-real-10 -freal-4-real-16 -freal-4-real-8 -freal-8-real-10 @gol
> --freal-8-real-16 -freal-8-real-4 -std=@var{std} -ftest-forall-temp
> +-freal-8-real-16 -freal-8-real-4 -std=@var{std} -ftest-forall-temp @gol
> +-freal-16=ibm -freal-16=ieee
>  }
>
>
> Remark: I am not sure if there will be an equivalent flag for C or C++.
> If there is, we could make this an alias, or use the C/C++ flag instead
> of a Fortran-specific one.
>
> We will have to have some way of compiling the REAL(KIND=16) library
> functions twice with the appropriate flag and also some additional
> name mangling, for which a little bit of m4 hackery will be needed.
>
>
>  @item Preprocessing Options
> @@ -539,6 +540,34 @@ when passing a value to the @code{kind=} dummy argument.  Inspection of the
>  intermediate representation of the translated Fortran code, produced by
>  @option{-fdump-fortran-original} or @option{-fdump-tree-original}, is suggested.
>
> +@item -freal-16=ibm
> +@item -freal-16=ieee
> +@opindex @code{freal-16=ibm}
> +@opindex @code{freal-16=ieee}
> +These options are only available on POWER systems.  They select
> +between the two possible formats available on POWER systems for
> +@code{REAL(KIND=16)} variables.  The ``IBM'' format consists of two
> +doubles (also known as @code{double double} or @code{__ibm128} and
> +the ``IEEE'' format of a 16-byte number in the format specified by
> +``IEEE 754'' (also known as @code{__ieee128}).
> +
> +The default is @code{-freal-16=ibm}.
> +
> +These options change the ABI of the code.  Code containing
> +@code{REAL=16} values compiled with one of these options is
> +@emph{incompatible} with code compiled with the other option.  The
> +compiler might or might not detect such incompatibilites, or they
> +might lead to silent data corruption.
> +
> +In gfortran 11 or earlier, only the ``IBM'' format of
> +@code{REAL(KIND=16)} was supported.
> +
> +The @ref{CONVERT specifier} can be used to read or write data
> +unformatted data containing @code{REAL(KIND=16)} in either the ``IBM''
> +or ``IEEE'' format, as can the @ref{GFORTRAN_CONVERT_UNIT} environment
> +variable and the @option{-fconvert} option.
> +
> +
>  @item -std=@var{std}
>  @opindex @code{std=}@var{std} option
>  Specify the standard to which the program is expected to conform,
> @@ -1404,6 +1433,42 @@ swap between big- and little-endian; @samp{big-endian}, use big-endian
>  representation for unformatted files; @samp{little-endian}, use little-endian
>  representation for unformatted files.
>
> +For POWER systems, there are additional options which specify if the
> +``IEEE'' or the ``IBM'' format are used for @code{REAL(KIND=16)} variables
> +for unformatted I/O.  Valid are:
> +@item @code{r16-ieee} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{native+r16-ieee} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{swap+r16-ieee} Swap between little- and big-endian,
> +use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{little-endian+r16-ieee} Use the little-endian format for
> +unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{big-endian+r16-ieee} Use the big-endian format for
> +unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{r16-ieee} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{native+r16-ieee} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{swap+r16-ieee} Swap between little- and big-endian,
> +use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{little-endian+r16-ieee} Use the little-endian format for
> +unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{big-endian+r16-ieee} Use the big-endian format for
> +unformatted files, use IEEE 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{r16-ibm} Use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{native+r16-ibm} Use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{swap+r16-ibm} Swap between little- and big-endian,
> +use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{little-endian+r16-ibm} Use the little-endian format for
> +unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{big-endian+r16-ibm} Use the big-endian format for
> +unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{r16-ibm} Use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{native+r16-ibm} Use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{swap+r16-ibm} Swap between little- and big-endian,
> +use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{little-endian+r16-ibm} Use the little-endian format for
> +unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
> +@item @code{big-endian+r16-ibm} Use the big-endian format for
> +unformatted files, use IBM 128-bit format for @code{REAL(KIND=16)}.
> +
>  @emph{This option has an effect only when used in the main program.
>  The @code{CONVERT} specifier and the GFORTRAN_CONVERT_UNIT environment
>  variable override the default specified by @option{-fconvert}.}
>
> Remark: Not sure if the '+' sign is a good idea in an option, or if we
> should use something else there.
>

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Thomas Koenig]

Hi Bill,

> We had previously been concerned about whether the
> necessary name mangling support would be possible, but it sounds like you aren't
> overly worried about that.

We can always add a letter to the kind number, or use a different
number in the encoding, or someting

This has to be done in fortran/iresolve.c, where the function
name is set, for example, in gfc_resolve_matmul, by


   f->value.function.name
     = gfc_get_string (PREFIX ("matmul_%c%d"), gfc_type_letter (f->ts.type),
		      f->ts.kind);

Easy enough to add something there if ts.type is BT_REAL,
ts.kind is 16 and the compiler is currently using
double double (for example), or just use KIND=15 then
(although that would only be a naming convention).

On the library side, it could become a bit harier, because there
is some m4 stuff going on there, and as we all know, m4 is sort
of a write-only language...

The place to look into are the macro definitions in
libgfortran/iparm/iparm.m4.  If we leave these alone
(which might be easier), we could then define GFC_REAL_15
to be IBM long double and change the Makefile.am to make
sure they are compiled with the right options.

As far as I can see, the rtype_kind and atype_kind numbers
are never used in calculations, just for namings, so we
should be safe.

As far as the other functions are concerned, we have the
list in gfortran.map.  Anything with _r16 should have a
_r15 equivalent.

Hmm... one question there.  I assume there is no problem if
something in gfortran.map is not present in the library file,
correct?  So, I think we should be able to put symbols there
which are unused on other systems.

So, I think the idea of differentiating the two real types
by the KIND number encoded in the file names should work.

Best regards

	Thomas

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Jakub Jelinek]

On Mon, Nov 01, 2021 at 06:32:51PM +0100, Thomas Koenig wrote:
>   f->value.function.name
>     = gfc_get_string (PREFIX ("matmul_%c%d"), gfc_type_letter (f->ts.type),
> 		      f->ts.kind);
> 
> Easy enough to add something there if ts.type is BT_REAL,
> ts.kind is 16 and the compiler is currently using
> double double (for example), or just use KIND=15 then
> (although that would only be a naming convention).

Note, if we go the way of C/C++ with -mabi=ieeelongdouble vs.
-mabi=ibmlongdouble choosing between the two ABIs and libgfortran being
ABI compatible with both, then we don't need to bump soname.
But, if we don't bump it, we need to keep double double there backwards
compatible (i.e. _r16 etc. being the double double, not IEEE).
When in the future we bump the soname, we can swap those two and
make _r16 newly stand for IEEE quad and _r15 or _r16d or whatever
for double double.

	Jakub

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Michael Meissner]

On Mon, Nov 01, 2021 at 10:54:27AM -0500, Bill Schmidt wrote:
> Hi Thomas,
> 
> To me this looks excellent.  If you feel that support for both forms is achievable,
> that's certainly superior.  We had previously been concerned about whether the
> necessary name mangling support would be possible, but it sounds like you aren't
> overly worried about that.
> 
> I'll let Mike weigh in about using the same options as are present for C/C++, which
> I think should be the right approach, but I know I don't know all the subtleties.
> That would also help determine whether -freal-16=ibm is the right default.  I think
> it probably is, but I'll let those more familiar with the details weigh in.
> 
> Thanks again!
> Bill

Lets see if I can describe the C/C++ side of things.

Internally, we have 3 floating point types:

 * KFmode: IEEE 128-bit

 * IFmode: IBM 128-bit

 * TFmode: What long double maps to (either IEEE 128-bit or IBM 128-bit)

In general, you should use TFmode if the 128-bit type matches long double, and
only use IFmode/KFmode if you are using a 128-bit type that does not match long
double.

We support 3 keywords:

 * __float128: Historic keywork for IEEE 128-bit (both C/C++)

 * _Float128: IEEE 128-bit (from ISO/IEC TS 18661-‐3:2015, C only)

 * __ibm128: Keyword to access current IBM 128-bit.

There are 2 naming conventions for 128-bit IEEE functions:

 * Libquadmath: Math functions end in 'q'.

 * ISO/IEC TS 18661-2:2015: Math functions end in 'f128'.

While we still build libquadmath, the C/C++ compiler and Glibc no longer
generate the 'q' names.  Instead we use the new names that end in f128.
Starting with glibc 2.34, the glibc library supports the f128 names on PowerPC
64-bit little endian systems.

As far as I know, glibc does not not provide the f128 names for big endian
systems.  We do build libquadmath and those interfaces could be used (much like
the x86_64 does), but you may get issues of whether you are using a 'q' or
'f128' function.

With glibc 2.34 and beyond, math.h remaps all of the math functions from 'l'
suffix to 'f128' suffix if long double is IEEE 128-bit.  In addition, the
PowerPC back end does this mapping for built-in functions if you call the
function without including math.h.  Hence if you build a toolchain that
defaults to IEEE 128-bit long double, Fortran calls to these functions are
mapped.

I believe glibc only does the IEEE 128-bit mapping if either long double is
IEEE 128-bit or:

 * __STDC_WANT_IEC_60559_FUNCS_EXT__ is defined.

 * __STDC_WANT_IEC_60559_TYPES_EXT__ might also need to be defined.

However, not all of the math functions have built-in counterparts to the name.
The compiler does not map these functions.

The libstdc++ library also does this mapping, starting wtih GCC 11.

While we typically talk of going between IBM and IEEE 128-bit long doubles, the
PowerPC compiler actually has 3 long double variants:

 * -mabi=ieeelongdouble: Long double is IEEE 128-bit if long doubles are
    128-bits.

 * -mabi=ibmlongdouble: Long double is IBM 128-bit if long doubles are
    128-bits.

 * -mlong-double-64: Long double is 64-bits and the -mabi=ieeelongdouble and
    -mabi=ibmlongdouble are not used.

The following macros are defined:

 * __LONG_DOUBLE_IEEE128__: if long doubles are IEEE 128-bit;

 * __LONG_DOUBLE_IBM128__: If long doubles are IBM 128-bit;

 * __LONG_DOUBLE_128__: If long doubles are 128-bits (either IBM or IEEE).

The ELF object file uses .gnu_attribute #4 to encode the current long double
format.  This is only set if calls are made using long double types (note, it
is somewhat buggy, and it misses things like using long double in the code, but
not doing a call, and the bit for 64-bit long doubles gets set if you pass or
return normal 64-bit doubles when the 64-bit long switch is set.  The bits are:

 * 0x1: Hardware 32/64-bit floating point is used.

 * 0x2: Software 32/64-bit floating point is used.  Note, this bit is not set
   if IEEE 128-bit is emulated (power8).

 * Bits 0x4 and 0x8 are a 2 bit field:

    * 0x4: 64-bit long doubles are passed and returned;
    * 0x8: IBM 128-bit long doubles are passed and returned;
    * 0xc: IEEE 128-bit long doubles are passed and returned.

If you are building libraries that contain modules with multiple long double
types, you must use the '-mno-gnu-attribute'.  We also use the '-Wno-psabi'
option, which silences the warning that you are switching long double types (if
glibc is not 2.34 or newer).  We may need to tweak -Wno-psabi for use with
Fortran.

For shared libraries, the linker complains if any of the modules in the library
set .gnu_attribute #4 to a different value than the current modules.  When
building the glibc and libstdc++ libraries

There are 3 configuration options to chose the long double type:

 * --with-long-double-format=ibm: Chooses IBM 128-bit long double;

 * --with-long-double-format=ieee: Chooses IEEE 128-bit long double;

 * --without-long-double-128: Choose 64-bit long double.

While I have tried to minimize the differences in running the test suites, if
you change the long double type, there will be changes in what tests pass or
fail.

 * A lot of the C++ modules tests fail when you switch the long double type.

 * 3 Fortran tests that tradionally fail, actually pass now.

 * There are a bunch of tests that fail when long double is 64-bits.

 * There are 2 C tests that fail due to issues with signalling NaNs with
   explicit _Float128 support that fail if long double is IEEE 128.

In order to build a toolchain that defaults to IEEE 128-bit long double (or
64-bit long double), I go through the following steps:

 * Build a standard toolchain (either stage1 or bootstrap);

 * Build gmp, mpfr, and mpc with that toolchain, using the appropriate long
   double option and the compiler built above.  I disable building shared
   libraries of these functions.  Even though the compiler does not call any
   long double function from these libraries, the libraries do define long
   double variants.

 * Build a stage1 compiler configured for the intended floating point type
   using the compiler built in the first step.

 * Using the stage1 compiler built in the third step, then build a bootstrap
   compiler.  In theory, you can omit the stage1 build, but I found it easier
   to debug things using the stage1 build instead of bootstrap.

With the hacks that I did last week, I suspect the path of least resistance to
the users is make KIND=16 match the long double format, and then have both
floating point modules in libgfortran.  On one hand, I can certainly understand
the position that long double should always be IEEE 128-bit and KIND=16, but
again people are using the existing support and don't want their code to
change.

It would be nice if we could make Fortran switch long double types via command
line (though in general, there are a lot of places that you run into when doing
this switch, such as using third party libraries).  It would also be nice if
users could explicitly ask for the IEEE 128-bit type.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Thomas Koenig]

On 01.11.21 18:45, Jakub Jelinek wrote:
> Note, if we go the way of C/C++ with -mabi=ieeelongdouble vs.
> -mabi=ibmlongdouble choosing between the two ABIs and libgfortran being
> ABI compatible with both, then we don't need to bump soname.

Sounds like one major pain solved.  I think we should do if it possible.

> But, if we don't bump it, we need to keep double double there backwards
> compatible (i.e. _r16 etc. being the double double, not IEEE).

Correct.  I would actually go for 17 for the IEEE because it is
the larger number, but that is a pure style issue and has no
impact on something that is user visible :-)

> When in the future we bump the soname, we can swap those two and
> make _r16 newly stand for IEEE quad and _r15 or _r16d or whatever
> for double double.

Yep.

We do need to do something about the generated module files, though, to
make programs compiled with one option incompatible with the other ones
on that level.

Or are people expected to get that right? :-)

Best regards

	Thomas

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Michael Meissner]

On Tue, Nov 02, 2021 at 07:19:10AM +0100, Thomas Koenig wrote:
> 
> On 01.11.21 18:45, Jakub Jelinek wrote:
> > Note, if we go the way of C/C++ with -mabi=ieeelongdouble vs.
> > -mabi=ibmlongdouble choosing between the two ABIs and libgfortran being
> > ABI compatible with both, then we don't need to bump soname.
> 
> Sounds like one major pain solved.  I think we should do if it possible.
> 
> > But, if we don't bump it, we need to keep double double there backwards
> > compatible (i.e. _r16 etc. being the double double, not IEEE).
> 
> Correct.  I would actually go for 17 for the IEEE because it is
> the larger number, but that is a pure style issue and has no
> impact on something that is user visible :-)
> 
> > When in the future we bump the soname, we can swap those two and
> > make _r16 newly stand for IEEE quad and _r15 or _r16d or whatever
> > for double double.
> 
> Yep.
> 
> We do need to do something about the generated module files, though, to
> make programs compiled with one option incompatible with the other ones
> on that level.

In general, I wouldn't expect mixing and matching long double options to work.
But you do want the library to have both versions of the library functions with
different names.

And as I've found out, outside of the official libraries, you run into smaller
libraries (like gmp, mpfr, and mpc used in the compiler) that also need to be
compiled with the right options because they have random functions that have
long double elements (even if the app doesn't use the long double arguments).
For example, in the C world, we need to have 3 versions of each of the *printf
functions, since printf can be passed long double.

> Or are people expected to get that right? :-)

In terms of testing, it isn't ideal, but if you make a branch that we (IBM) can
access, we can run it on our various systems.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Thomas Koenig]

Hi,

is there an update on this?  I am still waiting on a response for
the account on the development machine.

I assume we would to the development on a branch.  My git fu
is extremely weak, so I would appreciate if somebody did that
for me.

Is it actually possible to implement what I wrote in the draft
documentation patch, or is there some problem (like gmp
or mpfr depending on one of the types at compile-time)?

If so, I think we should go for it; if not, then we have to make
another decision.

Due to my day job, my time for working on this project is rather
limited, and in my experience it is easier to finish something if
it is actually started :-)

So, who does what?  I work on the gfortran internals (library interface)
and the library itself, but I would need some prior work to set up the
compiler so things work up to that particular point.

Or have we missed the window due to gcc being in stage 3 now?

Best regards

	Thomas

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Peter Bergner]

On 11/15/21 2:27 PM, Thomas Koenig wrote:
> I am still waiting on a response for the account on the development machine.

I haven't heard anything about the P9 partition either.
I'll ping OSU about that now.

Peter

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Michael Meissner]

On Mon, Nov 15, 2021 at 09:27:38PM +0100, Thomas Koenig wrote:
> Hi,
> 
> is there an update on this?  I am still waiting on a response for
> the account on the development machine.
> 
> I assume we would to the development on a branch.  My git fu
> is extremely weak, so I would appreciate if somebody did that
> for me.

Sure, we can create an IBM vendor branch.

> Is it actually possible to implement what I wrote in the draft
> documentation patch, or is there some problem (like gmp
> or mpfr depending on one of the types at compile-time)?
> 
> If so, I think we should go for it; if not, then we have to make
> another decision.

Well there are a couple of things that need to be done.  A lot are fortran
specific type things, so while I can attempt to do these things, I don't know
the structure of the front end or library.

From my previous test patches, I think it is a disaster if KIND=16 is not the
same as C/C++ long double by default.  It opens up all sorts of problems.  But
then it may be the Fortran users would like that flexibility.  That is your
call.

I think the most important thing is defining the library interface and naming
scheme.  So we need to switch calls to one name or another based on the default
long double format.  I don't know what naming scheme you use, but it should be
fairly simple.

For the C/C++/math built-ins, we use the traditional name with an 'l' suffix if
long double is IBM double-double, and a 'f128' suffix if long double is IEEE
128-bit.  The PowerPC backend will automatically switch names for built-ins it
knows about.

However, my tests showed there are a bunch of functions that are in the math
library that are not built-ins.  For C/C++, this is not an issue, because
math.h will do this switching.  We would need some way for Fortran to do it for
the other functions.

Once we have the naming scheme, then we need to modify the library build, so
that it will build both types of modules with the appropriate flags.

Once the library is set up to have both names, then we can start to think about
the user overriding the defaults.  This is probably a thing that needs the
Fortran folk to do, since there may be various rules of what can be done.  But
for the initial work, I think the most important thing is getting the library
so it has both names in it, so a user/distro could start to move the default
floating point type.

> Due to my day job, my time for working on this project is rather
> limited, and in my experience it is easier to finish something if
> it is actually started :-)
> 
> So, who does what?  I work on the gfortran internals (library interface)
> and the library itself, but I would need some prior work to set up the
> compiler so things work up to that particular point.
> 
> Or have we missed the window due to gcc being in stage 3 now?

This may be an issue for the release and Fortran maintainers.  Even if we can't
put it in right now, I think it is important to start work so it can be put in
at a later date.

In terms of my schedule, I will be available for doing whatever is needed until
December 20th.  I have a hard stop then as I will be doing a family trip for
Christmas and I will not be available after that.  I won't be back until the
new year.  I believe Bill and Peter feel this is one of the most important uses
of my time in the next month or so.  But bear in mind, I don't know much about
the Fortran front end, nothing about the library, or knowing Fortran at all.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Thomas Koenig]

On 16.11.21 00:42, Michael Meissner wrote:
> On Mon, Nov 15, 2021 at 09:27:38PM +0100, Thomas Koenig wrote:
>> Hi,
>>
>> is there an update on this?  I am still waiting on a response for
>> the account on the development machine.
>>
>> I assume we would to the development on a branch.  My git fu
>> is extremely weak, so I would appreciate if somebody did that
>> for me.
> 
> Sure, we can create an IBM vendor branch.
> 
>> Is it actually possible to implement what I wrote in the draft
>> documentation patch, or is there some problem (like gmp
>> or mpfr depending on one of the types at compile-time)?
>>
>> If so, I think we should go for it; if not, then we have to make
>> another decision.
> 
> Well there are a couple of things that need to be done.  A lot are fortran
> specific type things, so while I can attempt to do these things, I don't know
> the structure of the front end or library.
> 
>From my previous test patches, I think it is a disaster if KIND=16 is not the
> same as C/C++ long double by default.  It opens up all sorts of problems.  But
> then it may be the Fortran users would like that flexibility.  That is your
> call.
> 
> I think the most important thing is defining the library interface and naming
> scheme.  So we need to switch calls to one name or another based on the default
> long double format.  I don't know what naming scheme you use, but it should be
> fairly simple.
> 
> For the C/C++/math built-ins, we use the traditional name with an 'l' suffix if
> long double is IBM double-double, and a 'f128' suffix if long double is IEEE
> 128-bit.  The PowerPC backend will automatically switch names for built-ins it
> knows about.

That is where I come in, I think.

> However, my tests showed there are a bunch of functions that are in the math
> library that are not built-ins.  For C/C++, this is not an issue, because
> math.h will do this switching.  We would need some way for Fortran to do it for
> the other functions.

OK.

Looking at a random sample, libgfortran/generated/maxloc0_4_r4.c , has

#if defined (HAVE_GFC_REAL_4) && defined (HAVE_GFC_INTEGER_4)

extern void maxloc0_4_r4 (gfc_array_i4 * const restrict retarray,
         gfc_array_r4 * const restrict array, GFC_LOGICAL_4);

which is expanded by m4 from maxloc0.m4, which in turn includes
iforeach.m4, which has

name`'rtype_qual`_'atype_code (rtype * const restrict retarray,
         atype * const restrict array, GFC_LOGICAL_4 back)

where the parameters are determined from the file name.  So we
can put in a file maxloc0_4_r17 into the normal build process,
which will give us

#if defined (HAVE_GFC_REAL_17) && defined (HAVE_GFC_INTEGER_4)

Next thing to do would be to put the file into libgfortran/Makefile.am,
making sure that it is compiled with the right options.  There will
have to be some condition on the compilation that we do not compile
the files on non-POWER-systems.

Next, we need to define GFC_REAL_17 as IEEE QP on POWER (only there
of course), probably in libgfortran/kinds-override.h.

For compiling, there has to be a flag in the compiler to let us
know what we are compiling for, so we can call the different
functions depending on the flag.

> Once we have the naming scheme, then we need to modify the library build, so
> that it will build both types of modules with the appropriate flags.

Yep.

> Once the library is set up to have both names, then we can start to think about
> the user overriding the defaults.  This is probably a thing that needs the
> Fortran folk to do, since there may be various rules of what can be done.  But
> for the initial work, I think the most important thing is getting the library
> so it has both names in it, so a user/distro could start to move the default
> floating point type.

I can start working on that, once the following are in (or documented):

- A global configure script that determines if there is a target which
   supports both IEEE QP and double double.

- A conditional suitable for Makefile.am on libgfortran to check for
   that condition

- A preprocessor directive in the compiler to check if IEEE and
   QP are supported with the right flag

- A compiler flag to select either IEEE QP or double double as default

- A global flag to check if IEEE or double double is enabled



>> Due to my day job, my time for working on this project is rather
>> limited, and in my experience it is easier to finish something if
>> it is actually started :-)
>>
>> So, who does what?  I work on the gfortran internals (library interface)
>> and the library itself, but I would need some prior work to set up the
>> compiler so things work up to that particular point.
>>
>> Or have we missed the window due to gcc being in stage 3 now?
> 
> This may be an issue for the release and Fortran maintainers.  Even if we can't
> put it in right now, I think it is important to start work so it can be put in
> at a later date.

I'd say we would need a global reviewer's OK for that, plus of course
from a POWER maintainer, but that should not be a problem :-)

> In terms of my schedule, I will be available for doing whatever is needed until
> December 20th.  I have a hard stop then as I will be doing a family trip for
> Christmas and I will not be available after that.  I won't be back until the
> new year.  I believe Bill and Peter feel this is one of the most important uses
> of my time in the next month or so.  But bear in mind, I don't know much about
> the Fortran front end, nothing about the library, or knowing Fortran at all.

If you could start working on the points above, that would be great.

Best regards

	Thomas

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Jakub Jelinek]

On Tue, Nov 16, 2021 at 08:51:03AM +0100, Thomas Koenig wrote:
> If you could start working on the points above, that would be great.

Just small completely untested step, which IMHO should ensure that
on powerpc64le-*linux* (unless --with-long-double-64 configured)
we build libgfortran by default with -mabi=ibmlongdouble (so that
code using GFC_REAL_16 can use long double etc. and the kind 16 in
filenames stands for IBM long double), but the *_r17.F90 and *_c17.F90
files are built with -mabi=ieeelongdouble (for Fortran we need to choose
either one or another one but not both).  *_r17*.c and *_c17*.c can be
compiled with -mabi=ibmlongdouble because in C we can use __float128
(or __ieee128) or KF/KC mode to make it work with both kind 16 and "17"
in the same TU.
I bet the next step will be try to generate the generated m4 files
in maintainer mode and start fixing what needs to be fixed.
E.g. make sure that for the REAL_17/COMPLEX_17 cases we actually emit the
libquadmath functions or __*ieee128 functions depending on whether glibc
has support or not when using libm functions, I think there are some sources
that read kind from function descriptors and that would be probably 16
rather than 17 even for the IEEE long double, etc.
But that is as far as I can spend time on this right now.

--- libgfortran/configure.ac.jj	2021-09-23 10:07:16.011181551 +0200
+++ libgfortran/configure.ac	2021-11-19 15:07:29.505962930 +0100
@@ -145,6 +145,7 @@ AC_SUBST(CFLAGS)
 AM_PROG_CC_C_O
 
 # Add -Wall -fno-repack-arrays -fno-underscoring if we are using GCC.
+have_real_17=no
 if test "x$GCC" = "xyes"; then
   AM_FCFLAGS="-I . -Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring"
   ## We like to use C11 and C99 routines when available.  This makes
@@ -154,8 +155,24 @@ if test "x$GCC" = "xyes"; then
   ## Compile the following tests with the same system header contents
   ## that we'll encounter when compiling our own source files.
   CFLAGS="-std=gnu11 $CFLAGS"
-fi
 
+  case x$target in
+    powerpc64le*-linux*)
+      AC_PREPROC_IFELSE(
+        [AC_LANG_PROGRAM([[#if __SIZEOF_LONG_DOUBLE__ != 16
+			   #error long double is double
+			   #endif]],
+                         [[(void) 0;]])],
+        [AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble";
+	 AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble";
+	 CFLAGS="$CFLAGS -mabi=ibmlongdouble";
+	 have_real_17=yes])
+      ;;
+    *)
+      ;;
+  esac
+fi
+AM_CONDITIONAL([HAVE_REAL_17], [test "x$have_real_17" != xno])
 # Add CET specific flags if CET is enabled
 GCC_CET_FLAGS(CET_FLAGS)
 AM_FCFLAGS="$AM_FCFLAGS $CET_FLAGS"
@@ -665,10 +682,10 @@ LIBGFOR_CHECK_CRLF
 # Check whether we support AVX extensions
 LIBGFOR_CHECK_AVX
 
-# Check wether we support AVX2 extensions
+# Check whether we support AVX2 extensions
 LIBGFOR_CHECK_AVX2
 
-# Check wether we support AVX512f extensions
+# Check whether we support AVX512f extensions
 LIBGFOR_CHECK_AVX512F
 
 # Check for FMA3 extensions
--- libgfortran/kinds-override.h.jj	2021-01-04 10:25:54.764053433 +0100
+++ libgfortran/kinds-override.h	2021-11-19 14:28:05.799401414 +0100
@@ -44,3 +44,17 @@ see the files COPYING3 and COPYING.RUNTI
 # endif
 #endif
 
+#if defined(__powerpc64__) \
+    && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
+    && __SIZEOF_LONG_DOUBLE__ == 16 \
+    && defined(GFC_REAL_16_IS_LONG_DOUBLE)
+typedef __float128 GFC_REAL_17;
+typedef _Complex float __attribute__((mode(KC))) GFC_COMPLEX_17;
+#define HAVE_GFC_REAL_17
+#define HAVE_GFC_COMPLEX_17
+#define GFC_REAL_17_HUGE 1.18973149535723176508575932662800702e4932q
+#define GFC_REAL_17_LITERAL_SUFFIX q
+#define GFC_REAL_17_LITERAL(X) (X ## q)
+#define GFC_REAL_17_DIGITS 113
+#define GFC_REAL_17_RADIX 2
+#endif
--- libgfortran/Makefile.am.jj	2021-09-08 09:55:29.002718817 +0200
+++ libgfortran/Makefile.am	2021-11-19 15:08:01.634506758 +0100
@@ -241,7 +241,8 @@ i_bessel_c= \
 $(srcdir)/generated/bessel_r4.c \
 $(srcdir)/generated/bessel_r8.c \
 $(srcdir)/generated/bessel_r10.c \
-$(srcdir)/generated/bessel_r16.c
+$(srcdir)/generated/bessel_r16.c \
+$(srcdir)/generated/bessel_r17.c
 
 i_count_c= \
 $(srcdir)/generated/count_1_l.c \
@@ -281,10 +282,12 @@ $(srcdir)/generated/findloc0_r4.c \
 $(srcdir)/generated/findloc0_r8.c \
 $(srcdir)/generated/findloc0_r10.c \
 $(srcdir)/generated/findloc0_r16.c \
+$(srcdir)/generated/findloc0_r17.c \
 $(srcdir)/generated/findloc0_c4.c \
 $(srcdir)/generated/findloc0_c8.c \
 $(srcdir)/generated/findloc0_c10.c \
-$(srcdir)/generated/findloc0_c16.c
+$(srcdir)/generated/findloc0_c16.c \
+$(srcdir)/generated/findloc0_c17.c
 
 i_findloc0s_c= \
 $(srcdir)/generated/findloc0_s1.c \
@@ -300,10 +303,12 @@ $(srcdir)/generated/findloc1_r4.c \
 $(srcdir)/generated/findloc1_r8.c \
 $(srcdir)/generated/findloc1_r10.c \
 $(srcdir)/generated/findloc1_r16.c \
+$(srcdir)/generated/findloc1_r17.c \
 $(srcdir)/generated/findloc1_c4.c \
 $(srcdir)/generated/findloc1_c8.c \
 $(srcdir)/generated/findloc1_c10.c \
-$(srcdir)/generated/findloc1_c16.c
+$(srcdir)/generated/findloc1_c16.c \
+$(srcdir)/generated/findloc1_c17.c
 
 i_findloc1s_c= \
 $(srcdir)/generated/findloc1_s1.c \
@@ -340,7 +345,10 @@ $(srcdir)/generated/maxloc0_8_r10.c \
 $(srcdir)/generated/maxloc0_16_r10.c \
 $(srcdir)/generated/maxloc0_4_r16.c \
 $(srcdir)/generated/maxloc0_8_r16.c \
-$(srcdir)/generated/maxloc0_16_r16.c
+$(srcdir)/generated/maxloc0_16_r16.c \
+$(srcdir)/generated/maxloc0_4_r17.c \
+$(srcdir)/generated/maxloc0_8_r17.c \
+$(srcdir)/generated/maxloc0_16_r17.c
 
 i_maxloc0s_c = \
 $(srcdir)/generated/maxloc0_4_s1.c \
@@ -375,9 +383,12 @@ $(srcdir)/generated/maxloc1_16_r8.c \
 $(srcdir)/generated/maxloc1_4_r10.c \
 $(srcdir)/generated/maxloc1_8_r10.c \
 $(srcdir)/generated/maxloc1_16_r10.c \
-$(srcdir)/generated/maxloc1_4_r16.c \
+$(srcdir)/generated/maxloc1_4_r17.c \
 $(srcdir)/generated/maxloc1_8_r16.c \
-$(srcdir)/generated/maxloc1_16_r16.c
+$(srcdir)/generated/maxloc1_16_r16.c \
+$(srcdir)/generated/maxloc1_4_r17.c \
+$(srcdir)/generated/maxloc1_8_r17.c \
+$(srcdir)/generated/maxloc1_16_r17.c
 
 i_maxloc1s_c= \
 $(srcdir)/generated/maxloc1_4_s1.c \
@@ -404,7 +415,8 @@ $(srcdir)/generated/maxval_i16.c \
 $(srcdir)/generated/maxval_r4.c \
 $(srcdir)/generated/maxval_r8.c \
 $(srcdir)/generated/maxval_r10.c \
-$(srcdir)/generated/maxval_r16.c
+$(srcdir)/generated/maxval_r16.c \
+$(srcdir)/generated/maxval_r17.c
 
 i_maxval0s_c=\
 $(srcdir)/generated/maxval0_s1.c \
@@ -441,7 +453,10 @@ $(srcdir)/generated/minloc0_8_r10.c \
 $(srcdir)/generated/minloc0_16_r10.c \
 $(srcdir)/generated/minloc0_4_r16.c \
 $(srcdir)/generated/minloc0_8_r16.c \
-$(srcdir)/generated/minloc0_16_r16.c
+$(srcdir)/generated/minloc0_16_r16.c \
+$(srcdir)/generated/minloc0_4_r17.c \
+$(srcdir)/generated/minloc0_8_r17.c \
+$(srcdir)/generated/minloc0_16_r17.c
 
 i_minloc0s_c = \
 $(srcdir)/generated/minloc0_4_s1.c \
@@ -478,7 +493,10 @@ $(srcdir)/generated/minloc1_8_r10.c \
 $(srcdir)/generated/minloc1_16_r10.c \
 $(srcdir)/generated/minloc1_4_r16.c \
 $(srcdir)/generated/minloc1_8_r16.c \
-$(srcdir)/generated/minloc1_16_r16.c
+$(srcdir)/generated/minloc1_16_r16.c \
+$(srcdir)/generated/minloc1_4_r17.c \
+$(srcdir)/generated/minloc1_8_r17.c \
+$(srcdir)/generated/minloc1_16_r17.c
 
 i_minloc1s_c= \
 $(srcdir)/generated/minloc1_4_s1.c \
@@ -505,7 +523,8 @@ $(srcdir)/generated/minval_i16.c \
 $(srcdir)/generated/minval_r4.c \
 $(srcdir)/generated/minval_r8.c \
 $(srcdir)/generated/minval_r10.c \
-$(srcdir)/generated/minval_r16.c
+$(srcdir)/generated/minval_r16.c \
+$(srcdir)/generated/minval_r17.c
 
 i_minval0s_c=\
 $(srcdir)/generated/minval0_s1.c \
@@ -519,7 +538,8 @@ i_norm2_c= \
 $(srcdir)/generated/norm2_r4.c \
 $(srcdir)/generated/norm2_r8.c \
 $(srcdir)/generated/norm2_r10.c \
-$(srcdir)/generated/norm2_r16.c
+$(srcdir)/generated/norm2_r16.c \
+$(srcdir)/generated/norm2_r17.c
 
 i_parity_c = \
 $(srcdir)/generated/parity_l1.c \
@@ -538,10 +558,12 @@ $(srcdir)/generated/sum_r4.c \
 $(srcdir)/generated/sum_r8.c \
 $(srcdir)/generated/sum_r10.c \
 $(srcdir)/generated/sum_r16.c \
+$(srcdir)/generated/sum_r17.c \
 $(srcdir)/generated/sum_c4.c \
 $(srcdir)/generated/sum_c8.c \
 $(srcdir)/generated/sum_c10.c \
-$(srcdir)/generated/sum_c16.c
+$(srcdir)/generated/sum_c16.c \
+$(srcdir)/generated/sum_c17.c
 
 i_product_c= \
 $(srcdir)/generated/product_i1.c \
@@ -553,10 +575,12 @@ $(srcdir)/generated/product_r4.c \
 $(srcdir)/generated/product_r8.c \
 $(srcdir)/generated/product_r10.c \
 $(srcdir)/generated/product_r16.c \
+$(srcdir)/generated/product_r17.c \
 $(srcdir)/generated/product_c4.c \
 $(srcdir)/generated/product_c8.c \
 $(srcdir)/generated/product_c10.c \
-$(srcdir)/generated/product_c16.c
+$(srcdir)/generated/product_c16.c \
+$(srcdir)/generated/product_c17.c
 
 i_matmul_c= \
 $(srcdir)/generated/matmul_i1.c \
@@ -568,10 +592,12 @@ $(srcdir)/generated/matmul_r4.c \
 $(srcdir)/generated/matmul_r8.c \
 $(srcdir)/generated/matmul_r10.c \
 $(srcdir)/generated/matmul_r16.c \
+$(srcdir)/generated/matmul_r17.c \
 $(srcdir)/generated/matmul_c4.c \
 $(srcdir)/generated/matmul_c8.c \
 $(srcdir)/generated/matmul_c10.c \
-$(srcdir)/generated/matmul_c16.c
+$(srcdir)/generated/matmul_c16.c \
+$(srcdir)/generated/matmul_c17.c
 
 i_matmulavx128_c= \
 $(srcdir)/generated/matmulavx128_i1.c \
@@ -583,10 +609,12 @@ $(srcdir)/generated/matmulavx128_r4.c \
 $(srcdir)/generated/matmulavx128_r8.c \
 $(srcdir)/generated/matmulavx128_r10.c \
 $(srcdir)/generated/matmulavx128_r16.c \
+$(srcdir)/generated/matmulavx128_r17.c \
 $(srcdir)/generated/matmulavx128_c4.c \
 $(srcdir)/generated/matmulavx128_c8.c \
 $(srcdir)/generated/matmulavx128_c10.c \
-$(srcdir)/generated/matmulavx128_c16.c
+$(srcdir)/generated/matmulavx128_c16.c \
+$(srcdir)/generated/matmulavx128_c17.c;
 
 i_matmull_c= \
 $(srcdir)/generated/matmul_l4.c \
@@ -608,10 +636,12 @@ $(srcdir)/generated/reshape_r4.c \
 $(srcdir)/generated/reshape_r8.c \
 $(srcdir)/generated/reshape_r10.c \
 $(srcdir)/generated/reshape_r16.c \
+$(srcdir)/generated/reshape_r17.c \
 $(srcdir)/generated/reshape_c4.c \
 $(srcdir)/generated/reshape_c8.c \
 $(srcdir)/generated/reshape_c10.c \
-$(srcdir)/generated/reshape_c16.c
+$(srcdir)/generated/reshape_c16.c \
+$(srcdir)/generated/reshape_c17.c
 
 i_eoshift1_c= \
 $(srcdir)/generated/eoshift1_4.c \
@@ -633,10 +663,12 @@ $(srcdir)/generated/cshift0_r4.c \
 $(srcdir)/generated/cshift0_r8.c \
 $(srcdir)/generated/cshift0_r10.c \
 $(srcdir)/generated/cshift0_r16.c \
+$(srcdir)/generated/cshift0_r17.c \
 $(srcdir)/generated/cshift0_c4.c \
 $(srcdir)/generated/cshift0_c8.c \
 $(srcdir)/generated/cshift0_c10.c \
-$(srcdir)/generated/cshift0_c16.c
+$(srcdir)/generated/cshift0_c16.c \
+$(srcdir)/generated/cshift0_c17.c
 
 i_cshift1_c= \
 $(srcdir)/generated/cshift1_4.c \
@@ -653,10 +685,12 @@ $(srcdir)/generated/cshift1_4_r4.c \
 $(srcdir)/generated/cshift1_4_r8.c \
 $(srcdir)/generated/cshift1_4_r10.c \
 $(srcdir)/generated/cshift1_4_r16.c \
+$(srcdir)/generated/cshift1_4_r17.c \
 $(srcdir)/generated/cshift1_4_c4.c \
 $(srcdir)/generated/cshift1_4_c8.c \
 $(srcdir)/generated/cshift1_4_c10.c \
 $(srcdir)/generated/cshift1_4_c16.c \
+$(srcdir)/generated/cshift1_4_c17.c \
 $(srcdir)/generated/cshift1_8_i1.c \
 $(srcdir)/generated/cshift1_8_i2.c \
 $(srcdir)/generated/cshift1_8_i4.c \
@@ -666,10 +700,12 @@ $(srcdir)/generated/cshift1_8_r4.c \
 $(srcdir)/generated/cshift1_8_r8.c \
 $(srcdir)/generated/cshift1_8_r10.c \
 $(srcdir)/generated/cshift1_8_r16.c \
+$(srcdir)/generated/cshift1_8_r17.c \
 $(srcdir)/generated/cshift1_8_c4.c \
 $(srcdir)/generated/cshift1_8_c8.c \
 $(srcdir)/generated/cshift1_8_c10.c \
 $(srcdir)/generated/cshift1_8_c16.c \
+$(srcdir)/generated/cshift1_8_c17.c \
 $(srcdir)/generated/cshift1_16_i1.c \
 $(srcdir)/generated/cshift1_16_i2.c \
 $(srcdir)/generated/cshift1_16_i4.c \
@@ -679,10 +715,12 @@ $(srcdir)/generated/cshift1_16_r4.c \
 $(srcdir)/generated/cshift1_16_r8.c \
 $(srcdir)/generated/cshift1_16_r10.c \
 $(srcdir)/generated/cshift1_16_r16.c \
+$(srcdir)/generated/cshift1_16_r17.c \
 $(srcdir)/generated/cshift1_16_c4.c \
 $(srcdir)/generated/cshift1_16_c8.c \
 $(srcdir)/generated/cshift1_16_c10.c \
-$(srcdir)/generated/cshift1_16_c16.c
+$(srcdir)/generated/cshift1_16_c16.c \
+$(srcdir)/generated/cshift1_16_c17.c
 
 in_pack_c = \
 $(srcdir)/generated/in_pack_i1.c \
@@ -694,10 +732,12 @@ $(srcdir)/generated/in_pack_r4.c \
 $(srcdir)/generated/in_pack_r8.c \
 $(srcdir)/generated/in_pack_r10.c \
 $(srcdir)/generated/in_pack_r16.c \
+$(srcdir)/generated/in_pack_r17.c \
 $(srcdir)/generated/in_pack_c4.c \
 $(srcdir)/generated/in_pack_c8.c \
 $(srcdir)/generated/in_pack_c10.c \
-$(srcdir)/generated/in_pack_c16.c
+$(srcdir)/generated/in_pack_c16.c \
+$(srcdir)/generated/in_pack_c17.c
 
 in_unpack_c = \
 $(srcdir)/generated/in_unpack_i1.c \
@@ -709,20 +749,24 @@ $(srcdir)/generated/in_unpack_r4.c \
 $(srcdir)/generated/in_unpack_r8.c \
 $(srcdir)/generated/in_unpack_r10.c \
 $(srcdir)/generated/in_unpack_r16.c \
+$(srcdir)/generated/in_unpack_r17.c \
 $(srcdir)/generated/in_unpack_c4.c \
 $(srcdir)/generated/in_unpack_c8.c \
 $(srcdir)/generated/in_unpack_c10.c \
-$(srcdir)/generated/in_unpack_c16.c
+$(srcdir)/generated/in_unpack_c16.c \
+$(srcdir)/generated/in_unpack_c17.c
 
 i_pow_c = \
 $(srcdir)/generated/pow_i4_i4.c \
 $(srcdir)/generated/pow_i8_i4.c \
 $(srcdir)/generated/pow_i16_i4.c \
 $(srcdir)/generated/pow_r16_i4.c \
+$(srcdir)/generated/pow_r17_i4.c \
 $(srcdir)/generated/pow_c4_i4.c \
 $(srcdir)/generated/pow_c8_i4.c \
 $(srcdir)/generated/pow_c10_i4.c \
 $(srcdir)/generated/pow_c16_i4.c \
+$(srcdir)/generated/pow_c17_i4.c \
 $(srcdir)/generated/pow_i4_i8.c \
 $(srcdir)/generated/pow_i8_i8.c \
 $(srcdir)/generated/pow_i16_i8.c \
@@ -730,10 +774,12 @@ $(srcdir)/generated/pow_r4_i8.c \
 $(srcdir)/generated/pow_r8_i8.c \
 $(srcdir)/generated/pow_r10_i8.c \
 $(srcdir)/generated/pow_r16_i8.c \
+$(srcdir)/generated/pow_r17_i8.c \
 $(srcdir)/generated/pow_c4_i8.c \
 $(srcdir)/generated/pow_c8_i8.c \
 $(srcdir)/generated/pow_c10_i8.c \
 $(srcdir)/generated/pow_c16_i8.c \
+$(srcdir)/generated/pow_c17_i8.c \
 $(srcdir)/generated/pow_i4_i16.c \
 $(srcdir)/generated/pow_i8_i16.c \
 $(srcdir)/generated/pow_i16_i16.c \
@@ -741,10 +787,12 @@ $(srcdir)/generated/pow_r4_i16.c \
 $(srcdir)/generated/pow_r8_i16.c \
 $(srcdir)/generated/pow_r10_i16.c \
 $(srcdir)/generated/pow_r16_i16.c \
+$(srcdir)/generated/pow_r17_i16.c \
 $(srcdir)/generated/pow_c4_i16.c \
 $(srcdir)/generated/pow_c8_i16.c \
 $(srcdir)/generated/pow_c10_i16.c \
-$(srcdir)/generated/pow_c16_i16.c
+$(srcdir)/generated/pow_c16_i16.c \
+$(srcdir)/generated/pow_c17_i16.c
 
 i_pack_c = \
 $(srcdir)/generated/pack_i1.c \
@@ -756,10 +804,12 @@ $(srcdir)/generated/pack_r4.c \
 $(srcdir)/generated/pack_r8.c \
 $(srcdir)/generated/pack_r10.c \
 $(srcdir)/generated/pack_r16.c \
+$(srcdir)/generated/pack_r17.c \
 $(srcdir)/generated/pack_c4.c \
 $(srcdir)/generated/pack_c8.c \
 $(srcdir)/generated/pack_c10.c \
-$(srcdir)/generated/pack_c16.c
+$(srcdir)/generated/pack_c16.c \
+$(srcdir)/generated/pack_c17.c
 
 i_unpack_c = \
 $(srcdir)/generated/unpack_i1.c \
@@ -771,10 +821,12 @@ $(srcdir)/generated/unpack_r4.c \
 $(srcdir)/generated/unpack_r8.c \
 $(srcdir)/generated/unpack_r10.c \
 $(srcdir)/generated/unpack_r16.c \
+$(srcdir)/generated/unpack_r17.c \
 $(srcdir)/generated/unpack_c4.c \
 $(srcdir)/generated/unpack_c8.c \
 $(srcdir)/generated/unpack_c10.c \
-$(srcdir)/generated/unpack_c16.c
+$(srcdir)/generated/unpack_c16.c \
+$(srcdir)/generated/unpack_c17.c
 
 i_spread_c = \
 $(srcdir)/generated/spread_i1.c \
@@ -786,10 +838,12 @@ $(srcdir)/generated/spread_r4.c \
 $(srcdir)/generated/spread_r8.c \
 $(srcdir)/generated/spread_r10.c \
 $(srcdir)/generated/spread_r16.c \
+$(srcdir)/generated/spread_r17.c \
 $(srcdir)/generated/spread_c4.c \
 $(srcdir)/generated/spread_c8.c \
 $(srcdir)/generated/spread_c10.c \
-$(srcdir)/generated/spread_c16.c 
+$(srcdir)/generated/spread_c16.c \
+$(srcdir)/generated/spread_c17.c 
 
 i_isobinding_c = \
 $(srcdir)/runtime/ISO_Fortran_binding.c
@@ -830,6 +884,7 @@ $(srcdir)/generated/_abs_c4.F90 \
 $(srcdir)/generated/_abs_c8.F90 \
 $(srcdir)/generated/_abs_c10.F90 \
 $(srcdir)/generated/_abs_c16.F90 \
+$(srcdir)/generated/_abs_c17.F90 \
 $(srcdir)/generated/_abs_i4.F90 \
 $(srcdir)/generated/_abs_i8.F90 \
 $(srcdir)/generated/_abs_i16.F90 \
@@ -837,106 +892,132 @@ $(srcdir)/generated/_abs_r4.F90 \
 $(srcdir)/generated/_abs_r8.F90 \
 $(srcdir)/generated/_abs_r10.F90 \
 $(srcdir)/generated/_abs_r16.F90 \
+$(srcdir)/generated/_abs_r17.F90 \
 $(srcdir)/generated/_aimag_c4.F90 \
 $(srcdir)/generated/_aimag_c8.F90 \
 $(srcdir)/generated/_aimag_c10.F90 \
 $(srcdir)/generated/_aimag_c16.F90 \
+$(srcdir)/generated/_aimag_c17.F90 \
 $(srcdir)/generated/_exp_r4.F90 \
 $(srcdir)/generated/_exp_r8.F90 \
 $(srcdir)/generated/_exp_r10.F90 \
 $(srcdir)/generated/_exp_r16.F90 \
+$(srcdir)/generated/_exp_r17.F90 \
 $(srcdir)/generated/_exp_c4.F90 \
 $(srcdir)/generated/_exp_c8.F90 \
 $(srcdir)/generated/_exp_c10.F90 \
 $(srcdir)/generated/_exp_c16.F90 \
+$(srcdir)/generated/_exp_c17.F90 \
 $(srcdir)/generated/_log_r4.F90 \
 $(srcdir)/generated/_log_r8.F90 \
 $(srcdir)/generated/_log_r10.F90 \
 $(srcdir)/generated/_log_r16.F90 \
+$(srcdir)/generated/_log_r17.F90 \
 $(srcdir)/generated/_log_c4.F90 \
 $(srcdir)/generated/_log_c8.F90 \
 $(srcdir)/generated/_log_c10.F90 \
 $(srcdir)/generated/_log_c16.F90 \
+$(srcdir)/generated/_log_c17.F90 \
 $(srcdir)/generated/_log10_r4.F90 \
 $(srcdir)/generated/_log10_r8.F90 \
 $(srcdir)/generated/_log10_r10.F90 \
 $(srcdir)/generated/_log10_r16.F90 \
+$(srcdir)/generated/_log10_r17.F90 \
 $(srcdir)/generated/_sqrt_r4.F90 \
 $(srcdir)/generated/_sqrt_r8.F90 \
 $(srcdir)/generated/_sqrt_r10.F90 \
 $(srcdir)/generated/_sqrt_r16.F90 \
+$(srcdir)/generated/_sqrt_r17.F90 \
 $(srcdir)/generated/_sqrt_c4.F90 \
 $(srcdir)/generated/_sqrt_c8.F90 \
 $(srcdir)/generated/_sqrt_c10.F90 \
 $(srcdir)/generated/_sqrt_c16.F90 \
+$(srcdir)/generated/_sqrt_c17.F90 \
 $(srcdir)/generated/_asin_r4.F90 \
 $(srcdir)/generated/_asin_r8.F90 \
 $(srcdir)/generated/_asin_r10.F90 \
 $(srcdir)/generated/_asin_r16.F90 \
+$(srcdir)/generated/_asin_r17.F90 \
 $(srcdir)/generated/_asinh_r4.F90 \
 $(srcdir)/generated/_asinh_r8.F90 \
 $(srcdir)/generated/_asinh_r10.F90 \
 $(srcdir)/generated/_asinh_r16.F90 \
+$(srcdir)/generated/_asinh_r17.F90 \
 $(srcdir)/generated/_acos_r4.F90 \
 $(srcdir)/generated/_acos_r8.F90 \
 $(srcdir)/generated/_acos_r10.F90 \
 $(srcdir)/generated/_acos_r16.F90 \
+$(srcdir)/generated/_acos_r17.F90 \
 $(srcdir)/generated/_acosh_r4.F90 \
 $(srcdir)/generated/_acosh_r8.F90 \
 $(srcdir)/generated/_acosh_r10.F90 \
 $(srcdir)/generated/_acosh_r16.F90 \
+$(srcdir)/generated/_acosh_r17.F90 \
 $(srcdir)/generated/_atan_r4.F90 \
 $(srcdir)/generated/_atan_r8.F90 \
 $(srcdir)/generated/_atan_r10.F90 \
 $(srcdir)/generated/_atan_r16.F90 \
+$(srcdir)/generated/_atan_r17.F90 \
 $(srcdir)/generated/_atanh_r4.F90 \
 $(srcdir)/generated/_atanh_r8.F90 \
 $(srcdir)/generated/_atanh_r10.F90 \
 $(srcdir)/generated/_atanh_r16.F90 \
+$(srcdir)/generated/_atanh_r17.F90 \
 $(srcdir)/generated/_sin_r4.F90 \
 $(srcdir)/generated/_sin_r8.F90 \
 $(srcdir)/generated/_sin_r10.F90 \
 $(srcdir)/generated/_sin_r16.F90 \
+$(srcdir)/generated/_sin_r17.F90 \
 $(srcdir)/generated/_sin_c4.F90 \
 $(srcdir)/generated/_sin_c8.F90 \
 $(srcdir)/generated/_sin_c10.F90 \
 $(srcdir)/generated/_sin_c16.F90 \
+$(srcdir)/generated/_sin_c17.F90 \
 $(srcdir)/generated/_cos_r4.F90 \
 $(srcdir)/generated/_cos_r8.F90 \
 $(srcdir)/generated/_cos_r10.F90 \
 $(srcdir)/generated/_cos_r16.F90 \
+$(srcdir)/generated/_cos_r17.F90 \
 $(srcdir)/generated/_cos_c4.F90 \
 $(srcdir)/generated/_cos_c8.F90 \
 $(srcdir)/generated/_cos_c10.F90 \
 $(srcdir)/generated/_cos_c16.F90 \
+$(srcdir)/generated/_cos_c17.F90 \
 $(srcdir)/generated/_tan_r4.F90 \
 $(srcdir)/generated/_tan_r8.F90 \
 $(srcdir)/generated/_tan_r10.F90 \
 $(srcdir)/generated/_tan_r16.F90 \
+$(srcdir)/generated/_tan_r17.F90 \
 $(srcdir)/generated/_sinh_r4.F90 \
 $(srcdir)/generated/_sinh_r8.F90 \
 $(srcdir)/generated/_sinh_r10.F90 \
 $(srcdir)/generated/_sinh_r16.F90 \
+$(srcdir)/generated/_sinh_r17.F90 \
 $(srcdir)/generated/_cosh_r4.F90 \
 $(srcdir)/generated/_cosh_r8.F90 \
 $(srcdir)/generated/_cosh_r10.F90 \
 $(srcdir)/generated/_cosh_r16.F90 \
+$(srcdir)/generated/_cosh_r17.F90 \
 $(srcdir)/generated/_tanh_r4.F90 \
 $(srcdir)/generated/_tanh_r8.F90 \
 $(srcdir)/generated/_tanh_r10.F90 \
 $(srcdir)/generated/_tanh_r16.F90 \
+$(srcdir)/generated/_tanh_r17.F90 \
 $(srcdir)/generated/_conjg_c4.F90 \
 $(srcdir)/generated/_conjg_c8.F90 \
 $(srcdir)/generated/_conjg_c10.F90 \
 $(srcdir)/generated/_conjg_c16.F90 \
+$(srcdir)/generated/_conjg_c17.F90 \
 $(srcdir)/generated/_aint_r4.F90 \
 $(srcdir)/generated/_aint_r8.F90 \
 $(srcdir)/generated/_aint_r10.F90 \
 $(srcdir)/generated/_aint_r16.F90 \
+$(srcdir)/generated/_aint_r17.F90 \
 $(srcdir)/generated/_anint_r4.F90 \
 $(srcdir)/generated/_anint_r8.F90 \
 $(srcdir)/generated/_anint_r10.F90 \
-$(srcdir)/generated/_anint_r16.F90
+$(srcdir)/generated/_anint_r16.F90 \
+$(srcdir)/generated/_anint_r17.F90
 
 gfor_built_specific2_src= \
 $(srcdir)/generated/_sign_i4.F90 \
@@ -946,6 +1027,7 @@ $(srcdir)/generated/_sign_r4.F90 \
 $(srcdir)/generated/_sign_r8.F90 \
 $(srcdir)/generated/_sign_r10.F90 \
 $(srcdir)/generated/_sign_r16.F90 \
+$(srcdir)/generated/_sign_r17.F90 \
 $(srcdir)/generated/_dim_i4.F90 \
 $(srcdir)/generated/_dim_i8.F90 \
 $(srcdir)/generated/_dim_i16.F90 \
@@ -953,17 +1035,20 @@ $(srcdir)/generated/_dim_r4.F90 \
 $(srcdir)/generated/_dim_r8.F90 \
 $(srcdir)/generated/_dim_r10.F90 \
 $(srcdir)/generated/_dim_r16.F90 \
+$(srcdir)/generated/_dim_r17.F90 \
 $(srcdir)/generated/_atan2_r4.F90 \
 $(srcdir)/generated/_atan2_r8.F90 \
 $(srcdir)/generated/_atan2_r10.F90 \
 $(srcdir)/generated/_atan2_r16.F90 \
+$(srcdir)/generated/_atan2_r17.F90 \
 $(srcdir)/generated/_mod_i4.F90 \
 $(srcdir)/generated/_mod_i8.F90 \
 $(srcdir)/generated/_mod_i16.F90 \
 $(srcdir)/generated/_mod_r4.F90 \
 $(srcdir)/generated/_mod_r8.F90 \
 $(srcdir)/generated/_mod_r10.F90 \
-$(srcdir)/generated/_mod_r16.F90
+$(srcdir)/generated/_mod_r16.F90 \
+$(srcdir)/generated/_mod_r17.F90
 
 gfor_misc_specifics = $(srcdir)/generated/misc_specifics.F90
 
@@ -989,6 +1074,11 @@ $(patsubst %.c,%.lo,$(notdir $(i_matmull
 $(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
 
+# Build *_r17.F90 and *_c17.F90 with additional -mabi=ieeelongdouble on powerpc64le-linux.
+if HAVE_REAL_17
+$(patsubst %.F90,%.lo,$(filter %_r17.F90 %_c17.F90 $(notdir $(gfor_specific_src)))): AM_FCFLAGS += -mabi=ieeelongdouble
+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


	Jakub

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Segher Boessenkool]

On Mon, Nov 15, 2021 at 06:42:18PM -0500, Michael Meissner wrote:
> > I assume we would to the development on a branch.  My git fu
> > is extremely weak, so I would appreciate if somebody did that
> > for me.
> 
> Sure, we can create an IBM vendor branch.

It should not be an IBM branch, we should not mix that with community
stuff.  Instead it should be in devel/.

I'll create it, but someone needs to come up with a good name.
Something better than the "kind16" I would do ;-)


Segher

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Thomas Koenig]

Hi Segher,

> On Mon, Nov 15, 2021 at 06:42:18PM -0500, Michael Meissner wrote:
>>> I assume we would to the development on a branch.  My git fu
>>> is extremely weak, so I would appreciate if somebody did that
>>> for me.
>>
>> Sure, we can create an IBM vendor branch.
> 
> It should not be an IBM branch, we should not mix that with community
> stuff.  Instead it should be in devel/.
> 
> I'll create it, but someone needs to come up with a good name.
> Something better than the "kind16" I would do ;-)

power-ieee128, maybe?  I do not think we need to adhere to the
somewhat outdated "rs6000" name :-)

Best regards

	Thomas

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Peter Bergner]

On 11/19/21 1:09 PM, Thomas Koenig wrote:
>> On Mon, Nov 15, 2021 at 06:42:18PM -0500, Michael Meissner wrote:
>>> Sure, we can create an IBM vendor branch.
>>
>> It should not be an IBM branch, we should not mix that with community
>> stuff.  Instead it should be in devel/.

Agreed, this would be better as a normal devel branch.


>> I'll create it, but someone needs to come up with a good name.
>> Something better than the "kind16" I would do ;-)
> 
> power-ieee128, maybe?  I do not think we need to adhere to the
> somewhat outdated "rs6000" name :-)

Or how about gfortran-ieee128?

Peter

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Segher Boessenkool]

On Fri, Nov 19, 2021 at 01:36:33PM -0600, Peter Bergner wrote:
> On 11/19/21 1:09 PM, Thomas Koenig wrote:
> >> On Mon, Nov 15, 2021 at 06:42:18PM -0500, Michael Meissner wrote:
> >>> Sure, we can create an IBM vendor branch.
> >>
> >> It should not be an IBM branch, we should not mix that with community
> >> stuff.  Instead it should be in devel/.
> 
> Agreed, this would be better as a normal devel branch.
> 
> 
> >> I'll create it, but someone needs to come up with a good name.
> >> Something better than the "kind16" I would do ;-)
> > 
> > power-ieee128, maybe?  I do not think we need to adhere to the
> > somewhat outdated "rs6000" name :-)
> 
> Or how about gfortran-ieee128?

I have created devel/power-ieee128.  Descriptive names are good, but so
are shorter names.


Segher

[power-iee128] How to specify linker flags

[Thomas Koenig]

Hi Michael,

> If you are building libraries that contain modules with multiple long double
> types, you must use the '-mno-gnu-attribute'.  We also use the '-Wno-psabi'
> option, which silences the warning that you are switching long double types (if
> glibc is not 2.34 or newer).  We may need to tweak -Wno-psabi for use with
> Fortran.

I am now at the point where the object files are also compiled correctly
for the gfortran specifics:

0000000000000000 <_gfortran_specific__abs_r17>:
    0:   09 00 43 f4     lxv     vs34,0(r3)
    4:   48 16 40 fc     xsabsqp v2,v2
    8:   20 00 80 4e     blr

However, the linker complains, as you said it would, about the different
formats:

/opt/at15.0/bin/ld: .libs/maxloc0_4_r16.o uses IBM long double, 
.libs/_abs_r17.o uses IEEE long double
/opt/at15.0/bin/ld: failed to merge target specific data of file 
.libs/_abs_r17.o

I know next to nothing about libtool, so I do not know how to
add the flags so the linker can find them.

Any pointers?

(I have not yet committed the changes because I do not want to
commit something that does not compile.  If anybody wants to
take a look, it's on the ieee128 virtual machine under
/home/tkoenig/ieee ).

Regards

	Thomas

Re: [power-iee128] How to specify linker flags

[Thomas Koenig]

On 02.01.22 23:58, Thomas Koenig wrote:
> Hi Michael,
> 
>> If you are building libraries that contain modules with multiple long 
>> double
>> types, you must use the '-mno-gnu-attribute'.  We also use the 
>> '-Wno-psabi'
>> option, which silences the warning that you are switching long double 
>> types (if
>> glibc is not 2.34 or newer).  We may need to tweak -Wno-psabi for use 
>> with
>> Fortran.
> 
> I am now at the point where the object files are also compiled correctly
> for the gfortran specifics:
> 
> 0000000000000000 <_gfortran_specific__abs_r17>:
>     0:   09 00 43 f4     lxv     vs34,0(r3)
>     4:   48 16 40 fc     xsabsqp v2,v2
>     8:   20 00 80 4e     blr
> 
> However, the linker complains, as you said it would, about the different
> formats:
> 
> /opt/at15.0/bin/ld: .libs/maxloc0_4_r16.o uses IBM long double, 
> .libs/_abs_r17.o uses IEEE long double
> /opt/at15.0/bin/ld: failed to merge target specific data of file 
> .libs/_abs_r17.o
> 
> I know next to nothing about libtool, so I do not know how to
> add the flags so the linker can find them.
> 
> Any pointers?

One additional point.  The linker does not understand
-mno-gnu-attribute:

$ /opt/at15.0/bin/ld -mno-gnu-attribute
/opt/at15.0/bin/ld: unrecognised emulation mode: no-gnu-attribute
Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim 
elf64ppc elf32ppc elf32ppclinux elf32ppcsim

So, waiting for info to proceed.

Best regards

	Thomas

Re: [power-iee128] How to specify linker flags

[Jakub Jelinek]

On Mon, Jan 03, 2022 at 11:19:21AM +0100, Thomas Koenig wrote:
> > > If you are building libraries that contain modules with multiple
> > > long double
> > > types, you must use the '-mno-gnu-attribute'.  We also use the
> > > '-Wno-psabi'
> > > option, which silences the warning that you are switching long
> > > double types (if
> > > glibc is not 2.34 or newer).  We may need to tweak -Wno-psabi for
> > > use with
> > > Fortran.
> > 
> > I am now at the point where the object files are also compiled correctly
> > for the gfortran specifics:
> > 
> > 0000000000000000 <_gfortran_specific__abs_r17>:
> >     0:   09 00 43 f4     lxv     vs34,0(r3)
> >     4:   48 16 40 fc     xsabsqp v2,v2
> >     8:   20 00 80 4e     blr
> > 
> > However, the linker complains, as you said it would, about the different
> > formats:
> > 
> > /opt/at15.0/bin/ld: .libs/maxloc0_4_r16.o uses IBM long double,
> > .libs/_abs_r17.o uses IEEE long double
> > /opt/at15.0/bin/ld: failed to merge target specific data of file
> > .libs/_abs_r17.o
> > 
> > I know next to nothing about libtool, so I do not know how to
> > add the flags so the linker can find them.
> > 
> > Any pointers?
> 
> One additional point.  The linker does not understand
> -mno-gnu-attribute:
> 
> $ /opt/at15.0/bin/ld -mno-gnu-attribute
> /opt/at15.0/bin/ld: unrecognised emulation mode: no-gnu-attribute
> Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim
> elf64ppc elf32ppc elf32ppclinux elf32ppcsim
> 
> So, waiting for info to proceed.

-mno-gnu-attribute isn't a linker flag, but a compiler flag.
And e.g. libstdc++ configure uses it while compiling itself on
powerpc*linux:
        LONG_DOUBLE_COMPAT_FLAGS="$LONG_DOUBLE_COMPAT_FLAGS -mno-gnu-attribute"
        # Check for IEEE128 support in libm:
        AC_CHECK_LIB(m, __frexpieee128,
                     [ac_ldbl_ieee128_in_libc=yes],
                     [ac_ldbl_ieee128_in_libc=no])
        if test $ac_ldbl_ieee128_in_libc = yes; then
          # Determine which long double format is the compiler's default:
          AC_TRY_COMPILE(, [
            #ifndef __LONG_DOUBLE_IEEE128__
            #error compiler defaults to ibm128
            #endif
          ], [ac_ldbl_ieee128_default=yes], [ac_ldbl_ieee128_default=no])
          # Library objects should use default long double format.
          if test "$ac_ldbl_ieee128_default" = yes; then
            LONG_DOUBLE_128_FLAGS="-mno-gnu-attribute"
            # Except for the ones that explicitly use these flags:
            LONG_DOUBLE_ALT128_COMPAT_FLAGS="-mabi=ibmlongdouble -mno-gnu-attribute -Wno-psabi"
          else
            LONG_DOUBLE_128_FLAGS="-mno-gnu-attribute"
            LONG_DOUBLE_ALT128_COMPAT_FLAGS="-mabi=ieeelongdouble -mno-gnu-attribute -Wno-psabi"
          fi
          AC_DEFINE([_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT],1,
                [Define if compatibility should be provided for alternative 128-bit long double formats.])
          port_specific_symbol_files="$port_specific_symbol_files \$(top_srcdir)/config/os/gnu-linux/ldbl-ieee128-extra.ver"
          ac_ldbl_alt128_compat=yes
        else
          ac_ldbl_alt128_compat=no
        fi
        ;;
The idea behind this is that libstdc++ is written such that it can handle
both IBM extended and IEEE quad long double, so its object files are
compatible with both.

So I think we want:
2022-01-03  Jakub Jelinek  <jakub@redhat.com>

	* configure.ac (Use -mno-gnu-attribute together with
	-mabi=ibmlongdouble or -mabi=ieeelongdouble.

--- libgfortran/configure.ac	2021-12-31 11:08:19.032835533 +0000
+++ libgfortran/configure.ac	2022-01-03 10:32:16.927834682 +0000
@@ -163,9 +163,9 @@ if test "x$GCC" = "xyes"; then
 			   #error long double is double
 			   #endif]],
                          [[(void) 0;]])],
-        [AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble";
-	 AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble";
-	 CFLAGS="$CFLAGS -mabi=ibmlongdouble";
+        [AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble -mno-gnu-attribute";
+	 AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute";
+	 CFLAGS="$CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute";
 	 have_real_17=yes])
       ;;
     *)


	Jakub

Re: [power-iee128] How to specify linker flags

[Segher Boessenkool]

Hi!

On Mon, Jan 03, 2022 at 11:19:21AM +0100, Thomas Koenig wrote:
> One additional point.  The linker does not understand
> -mno-gnu-attribute:

That is a GCC option, not an ld one.  If you use it to compile some
file there will be no .gnu.attributes section generated for that
translation unit.


Segher

[power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran

[Jakub Jelinek]

On Mon, Jan 03, 2022 at 11:33:32AM +0100, Jakub Jelinek wrote:
> The idea behind this is that libstdc++ is written such that it can handle
> both IBM extended and IEEE quad long double, so its object files are
> compatible with both.

Now tested on powerpc64le-linux (and together with the regenerated file),
ok for power-ieee128?

2022-01-03  Jakub Jelinek  <jakub@redhat.com>

	* configure.ac (Use -mno-gnu-attribute together with
	-mabi=ibmlongdouble or -mabi=ieeelongdouble.
	* configure: Regenerated.

--- libgfortran/configure.ac.jj	2021-12-31 11:08:19.032835533 +0000
+++ libgfortran/configure.ac	2022-01-03 10:32:16.927834682 +0000
@@ -163,9 +163,9 @@ if test "x$GCC" = "xyes"; then
 			   #error long double is double
 			   #endif]],
                          [[(void) 0;]])],
-        [AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble";
-	 AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble";
-	 CFLAGS="$CFLAGS -mabi=ibmlongdouble";
+        [AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble -mno-gnu-attribute";
+	 AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute";
+	 CFLAGS="$CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute";
 	 have_real_17=yes])
       ;;
     *)
--- libgfortran/configure.jj	2021-12-31 11:08:19.032835533 +0000
+++ libgfortran/configure	2022-01-03 13:55:38.684926082 +0000
@@ -6025,9 +6025,9 @@ main ()
 }
 _ACEOF
 if ac_fn_c_try_cpp "$LINENO"; then :
-  AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble";
-	 AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble";
-	 CFLAGS="$CFLAGS -mabi=ibmlongdouble";
+  AM_FCFLAGS="$AM_FCFLAGS -mabi=ibmlongdouble -mno-gnu-attribute";
+	 AM_CFLAGS="$AM_CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute";
+	 CFLAGS="$CFLAGS -mabi=ibmlongdouble -mno-gnu-attribute";
 	 have_real_17=yes
 fi
 rm -f conftest.err conftest.i conftest.$ac_ext


	Jakub

Re: [power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran

[Thomas Koenig]

Hi Jakub,

> On Mon, Jan 03, 2022 at 11:33:32AM +0100, Jakub Jelinek wrote:
>> The idea behind this is that libstdc++ is written such that it can handle
>> both IBM extended and IEEE quad long double, so its object files are
>> compatible with both.
> 
> Now tested on powerpc64le-linux (and together with the regenerated file),
> ok for power-ieee128?

Since you posted it, I had already tested this and included it into the
patch I pushed a couple of minutes ago.

So, OK, and I already pushed it :-)

Thanks a lot for your help in this!

Best regards

	Thomas

Re: [power-iee128] How to specify linker flags

[Michael Meissner]

On Sun, Jan 02, 2022 at 11:58:29PM +0100, Thomas Koenig wrote:
> Hi Michael,
> 
> > If you are building libraries that contain modules with multiple long double
> > types, you must use the '-mno-gnu-attribute'.  We also use the '-Wno-psabi'
> > option, which silences the warning that you are switching long double types (if
> > glibc is not 2.34 or newer).  We may need to tweak -Wno-psabi for use with
> > Fortran.
> 
> I am now at the point where the object files are also compiled correctly
> for the gfortran specifics:
> 
> 0000000000000000 <_gfortran_specific__abs_r17>:
>    0:   09 00 43 f4     lxv     vs34,0(r3)
>    4:   48 16 40 fc     xsabsqp v2,v2
>    8:   20 00 80 4e     blr
> 
> However, the linker complains, as you said it would, about the different
> formats:
> 
> /opt/at15.0/bin/ld: .libs/maxloc0_4_r16.o uses IBM long double,
> .libs/_abs_r17.o uses IEEE long double
> /opt/at15.0/bin/ld: failed to merge target specific data of file
> .libs/_abs_r17.o
> 
> I know next to nothing about libtool, so I do not know how to
> add the flags so the linker can find them.
> 
> Any pointers?
> 
> (I have not yet committed the changes because I do not want to
> commit something that does not compile.  If anybody wants to
> take a look, it's on the ieee128 virtual machine under
> /home/tkoenig/ieee ).

I'm just getting back into things after being off-line for the winter holidays.
As others have said, you need to use the GCC option -mno-gnu-attributes on any
module that handles one of the long double types if you are building libraries
that can handle both.

Note, for C/C++ languages, you should add -Wno-psabi to the options as well as
-mabi={ieee,ibm}longdouble.  This suppresses the warning that says you are
changing the long double type.  If you have configred GCC against GLIBC 2.32 or
newer, then you don't need the -Wno-psabi option.  Unfortunately, you can't use
-Wno-psabi on languages like Fortran.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com