On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote:
> On 07.10.21 05:35, Michael Meissner via Fortran wrote:
> > I tried this at one point. There are a lot of hidden assumptions that the
> > kind
> > number is the number of bytes. I'm sure it can be tracked down, but the
> > problem is with these assumptions is you can't prove a negative (i.e. you
> > never
> > know that you've missed some).
>
> So, summing up from the Fortran side, I'd say the best course of action
> is to
>
> - make KIND=16 into IEEE QP
>
> - bump the SONAME on on affected systems on POWER and nowhere else
>
> - have a preprocessor flag so we can #ifdef out code which is relevant
> only there
If for libgfortran purposes, we already have one.
> - provide a CONVERT option (have to think of a suitable syntax) to
> do unformatted I/O either in IEEE QP or double double, but only
> on affected systems, so people can set this either via a CONVERT
> option on open or an environment variable. For OPEN, we should
> extend the existing one, for an environment variable, I'd say
> we should use a new one and reuse the existing parsing routines.
So no extra KIND=15 support for double double?
The above essentially means unlike the C/C++ world where the decision
on what is long double we defer to distributions "when they are ready"
(at gcc configure time for the default, or to users through
-mabi=ieeelongdouble or -mabi=ibmlongdouble)
for the Fortran we'd make the decision on the GCC side (in GCC 11 and
earlier real(kind=16) is double double, in GCC 12+ on ppc64le
real(kind=16) is IEEE QP), regardless of the -mabi=*longdouble flags etc.
As Joseph mentioned, on the Fortran side doing that is easier than on
the C/C++ side, where there is e.g. the requirement for GLIBC 2.32 or later
for IEEE QP, for Fortran we'll need to decide at gcc configure time
and either build libquadmath for ppc64le too (if glibc is older than 2.32)
or use the libm stuff instead.
Oh, and I guess some small difficulties will there be in the C
compatibility, e.g. what to do iso_c_binding c_long_double and
c_long_double_complex, if C and Fortran agree (depending on gcc
configure time decision and -mabi=*longdouble) then it would be 16,
but it is unclear what can be done for the case where the C long double
doesn't have a corresponding Fortran kind... So maybe KIND=15 support
would be useful at least for that.
Jakub
