libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

On Wed, Oct 06, 2021 at 11:42:11PM -0400, Michael Meissner wrote:
> On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote:
> > 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.
> 
> It only has the support if you add the options to enable IEEE 128-bit support
> when compiling programs.  It is off by default.

You need -mvsx and -mfloat128, both on by default on power7 and later.

Without hardware QP support it will call __mulkf3 and friends.  But the
parameter passing is identical: in the high VSRs (i.e. the VRs).

There are no differences between BE and LE here.

> > Converting double-double to IEEE QP should not be hard or slow?
> 
> There are a lot of corner cases to get it right.  IIRC, there are a few values
> that double double can represent that are not expressable with exact precision
> in IEEE 128-bit.

Yes, but those are trivial to get right.  The value of a double-double
is the sum of both doubles.  The sign is the sign of the first component
though (which matters if adding -0. and +0.), that is all, all other
cases magically work out as wanted afaics.


Segher