On Fri, Oct 15, 2021 at 08:50:08AM -0500, Bill Schmidt wrote:
> Thanks, Jakub, for starting this discussion, and to everyone who weighed in.
> The conversation
> went in a number of different directions, so I'd like to summarize my
> understanding of points
> where I think there was agreement. I'd also like to separate out short-term
> considerations
> for powerpc64le and GCC 12 from other topics like supporting more targets.
>
> ===
>
> First, for the short-term. For powerpc64le only (little-endian, ELFv2 ABI)
> Thomas suggested
> that Fortran's best course of action is:
> - Change KIND=16 in GCC 12 from double-double to IEEE QP just for affected
> targets
> - Bump the SONAME just for affected targets
> - Have a preprocessor flag to help #ifdef out irrelevant code (which Jakub
> asserted exists)
> - Deal with binary (unformatted) I/O with a CONVERT option for OPEN, and/or
> an envvar, to
> allow selection between the two formats
>
> There was some discussion of dual-mangling names for Fortran, but this didn't
> seem practical
> because of a number of complicating factors.
>
> There is an open question about possibly using KIND=15 or KIND=17 to
> represent double-double
> going forward. It's not clear whether or not this is necessary, but some C
> compatibility
> scenarios were cited as possible motivations.
>
> There was some concern about SONAME numbers differing across architectures,
> but consensus
> seems to be that this can be handled.
>
> Summary: I didn't see any serious pushback to Thomas's suggested course of
> action, and the
> only major open question is about maintaining a KIND to represent
> double-double.
>
> ===
...
>
> Is this a fair summary of the results of the discussion?
For me yes.
As for a separate KIND!=16 for double-double, I've looked up Fortran 2018
standard wording and it seems that the ISO C Bindings actually don't require
such kind to exist, I believe
C_LONG_DOUBLE
should be -3 if -mabi=ibmlongdouble and we only support real KIND 4, 8 and
16 (last one IEEE quad), because it says that -3 stands for
"has neither the precision nor range" and when one compiles
integer function foo ()
foo = precision (0.0_16)
end function foo
integer function bar ()
bar = range (0.0_16)
end function bar
with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble
33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither
precision of C long double if it is double-double nor range matches anything.
If we do implement double-double support, I think KIND=15 would be better
than KIND=17, it is true that double-double has for certain numbers much
higher precision than IEEE quad, but the precision depends on the numbers
and most of the time is smaller, the range is always smaller. And
the PRECISION/RANGE intrinsic numbers are also both smaller.
Jakub
