Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

[Steve Kargl <sgk@troutmask.apl.washington.edu>]

On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote:
> Hi together,
> 
> > > On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > > > Hi,
> > > > 
> > > > > I cannot see if there is proper support for kind=17 in your patch;
> > > > > at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
> > > > > seem to have any related code.
> > > > 
> > > > Can real(kind=17) ever be an IEEE mode? If so, something seriously wrong happened, because the IEEE modules have no kind=17 mention in them anywhere.
> > > > 
> > > > Actually, where is the kind=17 documented?
> > > > 
> > > > FX
> > > 
> > > I was hoping for Thomas to come forward with some comment, as
> > > he was quite involved in related work.
> > > 
> > > There are several threads on IEEE128 for Power on the fortran ML
> > > e.g. around November/December 2021, January 2022.
> > > 
> > > I wasn't meaning to block your work, just wondering if the Power
> > > platform needs more attention here.
> > > 
> > 
> > % cd gcc/gccx/libgfortran
> > % grep HAVE_GFC_REAL_17 ieee/*
> > % troutmask:sgk[219] ls ieee
> > % ieee_arithmetic.F90     ieee_features.F90
> > % ieee_exceptions.F90     ieee_helper.c
> > 
> > There are zero hits for REAL(17) in the IEEE code.  If REAL(17)
> > is intended to be an IEEE-754 type, then it seems gfortran's
> > support was never added for it.  If anyone has access to a
> > power system, it's easy to test
> > 
> > program foo
> >     use ieee_arithmetic
> >     print *, ieee_support_datatype(1.e_17)
> > end program foo
> 
> The KIND=17 is a bit of a kludge.  It is not visible for
> user programs, they use KIND=16, but this is then translated
> to library calls as if it was KIND=17 if the IEEE 128-bit floats
> are selected:
> 
> $ cat ml.f90
> subroutine mm(a)
>   real(kind=16), dimension(:,:) :: a
>   print *,maxloc(a)
> end subroutine mm
> $ gfortran -S -mabi=ieeelongdouble ml.f90 && grep maxloc ml.s
>         bl _gfortran_maxloc0_4_r17
> $ gfortran -S  ml.f90 && grep maxloc ml.s
>         bl _gfortran_maxloc0_4_r16
> 
> On POWER, if IBM long double exists, it is GFC_REAL_16, with GFC_REAL_17
> being IEEE long double. Everywhere else, GFC_REAL_16 is IEEE long
> double.
> 
> If POWER gets the flag -mabi=ieeelongdouble, it uses IEEE long doubles.
> 
> If it gets the additionalflag -mcpu=power9 or -mcpu=power10, it uses
> the hardware instructions for the arithmetic instead of library calls.
> 

(trimming for length)

Thanks for the explanation.  As I likely will not use a POWER-based
system, I only loosely followed the discussion.  I don't remember
if ibm double-double is REAL(16) or REAL(17).  If ieee 128-bit is
REAL(16), then everything should (I believe) be okay.

> There is a virutal POWER machine at OSUL dedicated to the IEEE QP
> gfortran effort. It hasn't been used for some time, but it's still
> active. I just bootstrapped trunk there and ran all the IEEE from the
> testsuite manually, with
> 
> $ for a in *.f90; do echo "Testing $a"; gfortran -o $a.exe -fno-range-check
> -mcpu=power9 -mabi=ieeelongdouble -static-libgfortran $a signaling_1_c.c
> signaling_2_c.c ; ./$a.exe ; done 2>&1 | grep -v command-line
> Testing fma_1.f90

These could be misleading.  gfortran has pre-processor tokens
for REAL(10) and REAL(16).   If __GFC_REAL_16__ isn't defined
the ieee testing is skipped.

% cd gcc/gccx/gcc/fortran/
% grep __GFC_REAL_ *
cpp.cc: cpp_define (cpp_in, "__GFC_REAL_10__=1");
cpp.cc: cpp_define (cpp_in, "__GFC_REAL_16__=1");
invoke.texi:@code{__GFC_REAL_10__}, and @code{__GFC_REAL_16__}.
% more cpp.cc
...
  /* Pre-defined macros for non-required REAL kind types.  */
  for (gfc_real_info *rtype = gfc_real_kinds; rtype->kind != 0; rtype++)
    {
      if (rtype->kind == 10)
        cpp_define (cpp_in, "__GFC_REAL_10__=1");
      if (rtype->kind == 16)
        cpp_define (cpp_in, "__GFC_REAL_16__=1");
    }
...

Should we have a __GFC_REAL_17__?

% cd ../testsuite/gfortran.dg/
% grep __GFC_REAL ieee/*
ieee/dec_math_1.f90:  ! Note however that if both __GFC_REAL_10__ and __GFC_REAL_16__ are defined,
ieee/dec_math_1.f90:#if defined(__GFC_REAL_10__)
ieee/dec_math_1.f90:#elif defined(__GFC_REAL_16__)
ieee/dec_math_1.f90:#ifdef __GFC_REAL_10__
ieee/dec_math_1.f90:#elif defined(__GFC_REAL_16__)
ieee/dec_math_1.f90:#ifdef __GFC_REAL_16__
ieee/dec_math_1.f90:#elif defined(__GFC_REAL_10__)
ieee/ieee_11.F90:#ifdef __GFC_REAL_10__
ieee/ieee_11.F90:#ifdef __GFC_REAL_16__

-- 
Steve