On 05.10.21 23:54, Segher Boessenkool wrote:
Hi!
On Tue, Oct 05, 2021 at 10:16:47PM +0200, Thomas Koenig wrote:
On 04.10.21 16:14, Jakub Jelinek via Fortran wrote:
Based on some IRC discussion, yet another option would be bump libgfortran
SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean
always IEEE quad (starting with GCC 12) and if wanted add support for
real(kind=15) meaning double double.
Bumping the SONAME for everybody even on architectures which are
not affected (like x86 or ARM) does not really feel right. We will
probably have to do it sooner or later, at least to get PDTs right
(and for array descriptor reform), but we will then have to
do another SONAME change when we do that (it is certainly not
ready now).
You do not have to change soname more than once per release.
You could leave it at the old value for archs not affected. It is good
for everyone's sanity to keep the same numbers for all archs though, so,
just skip some for some archs.
That's the best way, I think - no disruption on all other systems.
Everyone who uses -static won't be hurt either way.
There is also the issue of binary data. If some user has written
out data in double double and wants to read it in as IEEE quad,
the results are going to be garbage. Another option for CONVERT
might be the solution to that, or, as you wrote, having a
REAL(KIND=15). It should be inaccessible via SELECTED_REAL_KIND,
though.
That means flipping the default on all PowerPC to no longer be double-
double. This means that you should have IEEE QP work everywhere, or the
people who do need more than double precision will have no recourse.
I think we can exclude big-endian POWER from this - they do not have
IEEE QP support, correct? So, exclude that from the SONAME change.
So this would only be critical for people on little-endian POWER8
who use double double. Hmm... can the POWER8 handle the IEEE QP
instructions, or would that be trap and emulate? What is the
plan there?
It will be great if you can do this at the same time, get all the pain
over with at the same time, have better results for everyone. Heck, you
only need the "kind=15" for compatibility then.
It would still mean that people would have to change their source code,
especially those who have followed the standard convention of
using selected_real_kind. Not sure what the consequences would be.
People who have data stored in the old format will be in a tough spot
no matter what. Presumably everyone will want to convert to the
standard format at some point.
In that case, extending the CONVERT option to the OPEN statement
might be the best way (plus the corresponding handling of the
environment variables and options). It would be slow, especially
when honoring NaN and INF, but people could at least read in data and
then write it out again.
Best regards
Thomas
