Hi Steve,
On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote:
[...]
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.
From a user standpoint, REAL(16) is always used. We only use the 17
as a marker in the library, and to be able to have library versions
of IBM long double co-reside with IEEE long double.
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.
Hmm... need to check. With the recently-built compiler:
$ cat tst.F90
program memain
#if __GFC_REAL_16__
print *,"__GFC_REAL_16 found"
#endif
#if __GFC_REAL_17__
print *,"__GFC_REAL_17 found"
#endif
print *,"digits is ",digits(1._16)
end program memain
$ gfortran -static-libgfortran tst.F90 && ./a.out
__GFC_REAL_16 found
digits is 106
$ gfortran -static-libgfortran -mabi=ieeelongdouble -mcpu=power9 tst.F90
&& ./a.out
__GFC_REAL_16 found
digits is 113
Looks clean.
[...]
Should we have a __GFC_REAL_17__?
I don't think we need it - REAL(KIND=17) is not supported in
the compiler (we discussed and rejected that), and people
who mix IBM long double and IEEE long double will have no
joy with their programs; they need to recompile everything.
But we may have to do something about the files in the
thelibgfortran/ieee subdirectory.
Best regards
Thomas
