libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> On 05.10.21 23:54, Segher Boessenkool wrote:
> >>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.

Not correct, no.  IEEE QP works fine in either endianness.

I don't know what the libraries do, but in GCC it works just fine.

> 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?

The registers used by the QP insns are the VRs.  Trying to use the QP
insns on a p8 will trap.  There is no kernel emulation for them afaik.

But, for p8 there is software emulation, that GCC can generate.  This
follows the ABI as for p9 and later.

> >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.

Yes, that is pain.  But pain once :-)

> >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.

Converting double-double to IEEE QP should not be hard or slow?


Segher