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

[Thomas Koenig <tkoenig@netcologne.de>]

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.

Having a POWER system isn't enough, it also needs the IBM "advance
toolchain", and (at least with current distros, which default to
ibm long double), you need to dance counterclockwise three
times... I mean you need to invoke configure with some special magic
like

configure \
         --prefix=$HOME \
         --enable-languages=c,c++,fortran \
         --disable-plugin \
         --enable-checking \
         --enable-stage1-checking \
         --enable-gnu-indirect-function \
         --disable-maintainer-mode \
         --disable-libgomp \
         --enable-decimal-float \
         --enable-secureplt \
         --enable-threads=posix \
         --enable-__cxa_atexit \
         --with-cpu=power9 \
         --with-long-double-128 \
         --with-as=/opt/at15.0/bin/as \
         --with-ld=/opt/at15.0/bin/ld \
         --with-gnu-as=/opt/at15.0/bin/as \
         --with-gnu-ld=/opt/at15.0/bin/ld \
         --with-advance-toolchain=at15.0 \
         --with-native-system-header-dir=/opt/at15.0/include \
         --without-ppl \
         --without-cloog \
         --without-isl

which Michael Meissner helped me with, I would never have figured it out
on my own.

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
    2.00000000
    1.50000000
    2.0000000000000000
    1.5000000000000000
    2.00000000000000000000000000000000000
    1.50000000000000000000000000000000000
    2.0000000000000000
    1.5000000000000000
Testing ieee_10.f90
Testing ieee_12.f90
Testing ieee_2.f90
Testing ieee_3.f90
Testing ieee_4.f90
Testing ieee_5.f90
Testing ieee_6.f90
Testing ieee_7.f90
Testing ieee_8.f90
Testing ieee_9.f90
Testing intrinsics_1.f90
Testing large_1.f90
Testing large_2.f90
Testing large_4.f90
Testing modes_1.f90
Testing pr77372.f90
Testing pr77507.f90
         -Infinity
  F
Testing rounding_1.f90
Testing rounding_2.f90
Testing rounding_3.f90
Testing signaling_1.f90
Testing signaling_2.f90
Testing signaling_3.f90
Testing signbit_1.f90
Testing underflow_1.f90

so that seems to be OK.  However, the fact that there is no
mention of GFC_REAL_17 in there makes me a bit suspicious,

Michael, maybe you can comment if all is indeed well there,
and if the right things are being tested?

Regarding FX's patch: I am not quite sure that I am
actually testing the right thing if running the testsuite
there, so POWER should not hold up this patch.  If it turns
out that POWER needs additonal work on IEEE, we can always
add that later.

Best regards

	Thomas