* [RFC] User-visible changes for powerpc64-le-linux ABI changes @ 2021-10-31 14:43 Thomas Koenig 2021-11-01 15:54 ` Bill Schmidt 0 siblings, 1 reply; 23+ messages in thread From: Thomas Koenig @ 2021-10-31 14:43 UTC (permalink / raw) To: fortran, Jakub Jelinek, Segher Boessenkool, Peter Bergner, Bill Schmidt, David Edelsohn, Michael Meissner 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-10-31 14:43 [RFC] User-visible changes for powerpc64-le-linux ABI changes Thomas Koenig @ 2021-11-01 15:54 ` Bill Schmidt 2021-11-01 17:32 ` Thomas Koenig 2021-11-01 18:46 ` Michael Meissner 0 siblings, 2 replies; 23+ messages in thread From: Bill Schmidt @ 2021-11-01 15:54 UTC (permalink / raw) To: Thomas Koenig, fortran, Jakub Jelinek, Segher Boessenkool, Peter Bergner, David Edelsohn, Michael Meissner 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. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-11-01 15:54 ` Bill Schmidt @ 2021-11-01 17:32 ` Thomas Koenig 2021-11-01 17:45 ` Jakub Jelinek 2021-11-01 18:46 ` Michael Meissner 1 sibling, 1 reply; 23+ messages in thread From: Thomas Koenig @ 2021-11-01 17:32 UTC (permalink / raw) To: wschmidt, fortran, Jakub Jelinek, Segher Boessenkool, Peter Bergner, David Edelsohn, Michael Meissner 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-11-01 17:32 ` Thomas Koenig @ 2021-11-01 17:45 ` Jakub Jelinek 2021-11-02 6:19 ` Thomas Koenig 0 siblings, 1 reply; 23+ messages in thread From: Jakub Jelinek @ 2021-11-01 17:45 UTC (permalink / raw) To: Thomas Koenig Cc: wschmidt, fortran, Segher Boessenkool, Peter Bergner, David Edelsohn, Michael Meissner 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-11-01 17:45 ` Jakub Jelinek @ 2021-11-02 6:19 ` Thomas Koenig 2021-11-04 4:41 ` Michael Meissner 0 siblings, 1 reply; 23+ messages in thread From: Thomas Koenig @ 2021-11-02 6:19 UTC (permalink / raw) To: Jakub Jelinek Cc: wschmidt, fortran, Segher Boessenkool, Peter Bergner, David Edelsohn, Michael Meissner 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-11-02 6:19 ` Thomas Koenig @ 2021-11-04 4:41 ` Michael Meissner 0 siblings, 0 replies; 23+ messages in thread From: Michael Meissner @ 2021-11-04 4:41 UTC (permalink / raw) To: Thomas Koenig Cc: Jakub Jelinek, wschmidt, fortran, Segher Boessenkool, Peter Bergner, David Edelsohn, 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-11-01 15:54 ` Bill Schmidt 2021-11-01 17:32 ` Thomas Koenig @ 2021-11-01 18:46 ` Michael Meissner 2021-11-15 20:27 ` Thomas Koenig 2022-01-02 22:58 ` [power-iee128] How to specify linker flags Thomas Koenig 1 sibling, 2 replies; 23+ messages in thread From: Michael Meissner @ 2021-11-01 18:46 UTC (permalink / raw) To: Bill Schmidt Cc: Thomas Koenig, fortran, Jakub Jelinek, Segher Boessenkool, Peter Bergner, David Edelsohn, 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-11-01 18:46 ` Michael Meissner @ 2021-11-15 20:27 ` Thomas Koenig 2021-11-15 22:14 ` Peter Bergner 2021-11-15 23:42 ` Michael Meissner 2022-01-02 22:58 ` [power-iee128] How to specify linker flags Thomas Koenig 1 sibling, 2 replies; 23+ messages in thread From: Thomas Koenig @ 2021-11-15 20:27 UTC (permalink / raw) To: Michael Meissner, Bill Schmidt, fortran, Jakub Jelinek, Segher Boessenkool, Peter Bergner, David Edelsohn 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-11-15 20:27 ` Thomas Koenig @ 2021-11-15 22:14 ` Peter Bergner 2021-11-15 23:42 ` Michael Meissner 1 sibling, 0 replies; 23+ messages in thread From: Peter Bergner @ 2021-11-15 22:14 UTC (permalink / raw) To: Thomas Koenig, Michael Meissner, Bill Schmidt, fortran, Jakub Jelinek, Segher Boessenkool, David Edelsohn 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-11-15 20:27 ` Thomas Koenig 2021-11-15 22:14 ` Peter Bergner @ 2021-11-15 23:42 ` Michael Meissner 2021-11-16 7:51 ` Thomas Koenig 2021-11-19 17:30 ` Segher Boessenkool 1 sibling, 2 replies; 23+ messages in thread From: Michael Meissner @ 2021-11-15 23:42 UTC (permalink / raw) To: Thomas Koenig Cc: Michael Meissner, Bill Schmidt, fortran, Jakub Jelinek, Segher Boessenkool, Peter Bergner, David Edelsohn 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-11-15 23:42 ` Michael Meissner @ 2021-11-16 7:51 ` Thomas Koenig 2021-11-19 14:19 ` Jakub Jelinek 2021-11-19 17:30 ` Segher Boessenkool 1 sibling, 1 reply; 23+ messages in thread From: Thomas Koenig @ 2021-11-16 7:51 UTC (permalink / raw) To: Michael Meissner, Bill Schmidt, fortran, Jakub Jelinek, Segher Boessenkool, Peter Bergner, David Edelsohn 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-11-16 7:51 ` Thomas Koenig @ 2021-11-19 14:19 ` Jakub Jelinek 0 siblings, 0 replies; 23+ messages in thread From: Jakub Jelinek @ 2021-11-19 14:19 UTC (permalink / raw) To: Thomas Koenig Cc: Michael Meissner, Bill Schmidt, fortran, Segher Boessenkool, Peter Bergner, David Edelsohn 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-11-15 23:42 ` Michael Meissner 2021-11-16 7:51 ` Thomas Koenig @ 2021-11-19 17:30 ` Segher Boessenkool 2021-11-19 19:09 ` Thomas Koenig 1 sibling, 1 reply; 23+ messages in thread From: Segher Boessenkool @ 2021-11-19 17:30 UTC (permalink / raw) To: Michael Meissner, Thomas Koenig, Bill Schmidt, fortran, Jakub Jelinek, Peter Bergner, David Edelsohn 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-11-19 17:30 ` Segher Boessenkool @ 2021-11-19 19:09 ` Thomas Koenig 2021-11-19 19:36 ` Peter Bergner 0 siblings, 1 reply; 23+ messages in thread From: Thomas Koenig @ 2021-11-19 19:09 UTC (permalink / raw) To: Segher Boessenkool, Michael Meissner, Bill Schmidt, fortran, Jakub Jelinek, Peter Bergner, David Edelsohn 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-11-19 19:09 ` Thomas Koenig @ 2021-11-19 19:36 ` Peter Bergner 2021-11-19 21:30 ` Segher Boessenkool 0 siblings, 1 reply; 23+ messages in thread From: Peter Bergner @ 2021-11-19 19:36 UTC (permalink / raw) To: Thomas Koenig, Segher Boessenkool, Michael Meissner, Bill Schmidt, fortran, Jakub Jelinek, David Edelsohn 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes 2021-11-19 19:36 ` Peter Bergner @ 2021-11-19 21:30 ` Segher Boessenkool 0 siblings, 0 replies; 23+ messages in thread From: Segher Boessenkool @ 2021-11-19 21:30 UTC (permalink / raw) To: Peter Bergner Cc: Thomas Koenig, Michael Meissner, Bill Schmidt, fortran, Jakub Jelinek, David Edelsohn 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* [power-iee128] How to specify linker flags 2021-11-01 18:46 ` Michael Meissner 2021-11-15 20:27 ` Thomas Koenig @ 2022-01-02 22:58 ` Thomas Koenig 2022-01-03 10:19 ` Thomas Koenig 2022-01-05 21:20 ` Michael Meissner 1 sibling, 2 replies; 23+ messages in thread From: Thomas Koenig @ 2022-01-02 22:58 UTC (permalink / raw) To: Michael Meissner, Bill Schmidt, fortran, Jakub Jelinek, Segher Boessenkool, Peter Bergner, David Edelsohn, gcc mailing list 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [power-iee128] How to specify linker flags 2022-01-02 22:58 ` [power-iee128] How to specify linker flags Thomas Koenig @ 2022-01-03 10:19 ` Thomas Koenig 2022-01-03 10:33 ` Jakub Jelinek 2022-01-03 10:34 ` [power-iee128] How to specify linker flags Segher Boessenkool 2022-01-05 21:20 ` Michael Meissner 1 sibling, 2 replies; 23+ messages in thread From: Thomas Koenig @ 2022-01-03 10:19 UTC (permalink / raw) To: Michael Meissner, Bill Schmidt, fortran, Jakub Jelinek, Segher Boessenkool, Peter Bergner, David Edelsohn, gcc mailing list 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [power-iee128] How to specify linker flags 2022-01-03 10:19 ` Thomas Koenig @ 2022-01-03 10:33 ` Jakub Jelinek 2022-01-03 15:23 ` [power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran Jakub Jelinek 2022-01-03 10:34 ` [power-iee128] How to specify linker flags Segher Boessenkool 1 sibling, 1 reply; 23+ messages in thread From: Jakub Jelinek @ 2022-01-03 10:33 UTC (permalink / raw) To: Thomas Koenig Cc: Michael Meissner, Bill Schmidt, fortran, Segher Boessenkool, Peter Bergner, David Edelsohn, gcc mailing list 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* [power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran 2022-01-03 10:33 ` Jakub Jelinek @ 2022-01-03 15:23 ` Jakub Jelinek 2022-01-03 15:27 ` Thomas Koenig 0 siblings, 1 reply; 23+ messages in thread From: Jakub Jelinek @ 2022-01-03 15:23 UTC (permalink / raw) To: Thomas Koenig Cc: Michael Meissner, Bill Schmidt, fortran, Segher Boessenkool, Peter Bergner, David Edelsohn, gcc-patches 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran 2022-01-03 15:23 ` [power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran Jakub Jelinek @ 2022-01-03 15:27 ` Thomas Koenig 0 siblings, 0 replies; 23+ messages in thread From: Thomas Koenig @ 2022-01-03 15:27 UTC (permalink / raw) To: Jakub Jelinek Cc: Michael Meissner, Bill Schmidt, fortran, Segher Boessenkool, Peter Bergner, David Edelsohn, gcc-patches 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [power-iee128] How to specify linker flags 2022-01-03 10:19 ` Thomas Koenig 2022-01-03 10:33 ` Jakub Jelinek @ 2022-01-03 10:34 ` Segher Boessenkool 1 sibling, 0 replies; 23+ messages in thread From: Segher Boessenkool @ 2022-01-03 10:34 UTC (permalink / raw) To: Thomas Koenig Cc: Michael Meissner, Bill Schmidt, fortran, Jakub Jelinek, Peter Bergner, David Edelsohn, gcc mailing list 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [power-iee128] How to specify linker flags 2022-01-02 22:58 ` [power-iee128] How to specify linker flags Thomas Koenig 2022-01-03 10:19 ` Thomas Koenig @ 2022-01-05 21:20 ` Michael Meissner 1 sibling, 0 replies; 23+ messages in thread From: Michael Meissner @ 2022-01-05 21:20 UTC (permalink / raw) To: Thomas Koenig Cc: Michael Meissner, Bill Schmidt, fortran, Jakub Jelinek, Segher Boessenkool, Peter Bergner, David Edelsohn, gcc mailing list 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2022-01-05 21:20 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-31 14:43 [RFC] User-visible changes for powerpc64-le-linux ABI changes Thomas Koenig 2021-11-01 15:54 ` Bill Schmidt 2021-11-01 17:32 ` Thomas Koenig 2021-11-01 17:45 ` Jakub Jelinek 2021-11-02 6:19 ` Thomas Koenig 2021-11-04 4:41 ` Michael Meissner 2021-11-01 18:46 ` Michael Meissner 2021-11-15 20:27 ` Thomas Koenig 2021-11-15 22:14 ` Peter Bergner 2021-11-15 23:42 ` Michael Meissner 2021-11-16 7:51 ` Thomas Koenig 2021-11-19 14:19 ` Jakub Jelinek 2021-11-19 17:30 ` Segher Boessenkool 2021-11-19 19:09 ` Thomas Koenig 2021-11-19 19:36 ` Peter Bergner 2021-11-19 21:30 ` Segher Boessenkool 2022-01-02 22:58 ` [power-iee128] How to specify linker flags Thomas Koenig 2022-01-03 10:19 ` Thomas Koenig 2022-01-03 10:33 ` Jakub Jelinek 2022-01-03 15:23 ` [power-iee128] libgfortran: Use -mno-gnu-attribute in libgfortran Jakub Jelinek 2022-01-03 15:27 ` Thomas Koenig 2022-01-03 10:34 ` [power-iee128] How to specify linker flags Segher Boessenkool 2022-01-05 21:20 ` Michael Meissner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).