libgfortran.so SONAME and powerpc64le-linux ABI changes

libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek]

Hi!

On powerpc64le-linux target, one can select between two incompatible
long double formats (both of them are 16-byte), __ibm128 which is
a sum of two doubles, and __float128 (note, not implemented through
libquadmath), which is IEEE754 quad format.  The default for
long double can be selected with --with-long-double-format={ieee,ibm}
configure options.
AFAIK no distributions switched to --with-long-double-format=ieee
yet (correct me if I'm wrong), but the goal is that eventually all
distros switch to that (like they've switched from the --with-long-double-64
default to --with-long-double-128 on powerpc64-linux, s390*-linux etc. years
ago).

libstdc++ has been changed already last year, so that the same
libstdc++.so.6 is ABI compatible with both configurations, in C++ the
IEEE quad long double mangles differently from IBM double double long
double and so it is possible (with quite some work) to achieve that.
Other C++ libraries not shipped as part of gcc are either lucky and don't
use long double on any of its public APIs, then they are compatible with
both, or developers can go the same painful way and support both ABIs in
the same shared library, or they are simply ABI incompatible.

But, I believe --with-long-double-format={ieee,ibm} configure time choice
doesn't change just the meaning of long double, but also of real(kind=16)
and complex(kind=32), but Fortran name mangling just appends _ and doesn't
encode types.
So, the choices for libgfortran.so.5 are either don't do anything, then
we have from GCC the same SONAME but based on what --with-long-double-format={ieee,ibm}
distributions choose ABI incompatible libraries, or bump libgfortran
SONAME in GCC 12 on all targets (the problem is that it unnecessarily
changes the SONAME even on targets that don't really need it - unless
there are important ABI changes in the queue for GCC 12 already), but
that to be effective would basically require that all distros change to
--with-long-double-format=ieee together with GCC 12, or change the
SONAME only on powerpc64le somehow (still the problem that all distros
have to change at once), or add some kind=16 suffix letter into the SONAME
if configured --with-long-double-format=ieee (so we'd have
libgfortran.so.5ieee or whatever, and when we'd bump to libgfortran.so.6
on all arches libgfortran.so.6ieee etc.).

Or the last option would be to try to make libgfortran.so.5 ABI compatible
with both choices on powerpc64le-linux.  From quick skimming of libgfortran,
we have lots of generated functions, which use HAVE_GFC_REAL_16 and
GFC_REAL_16 etc. macros.  So, we could perhaps arrange for the compiler
to use r16i or r17 instead of r16 in the names when real(kind=16) is the
IEEE quad on powerpc64le and keep using r16 for the IBM double double.
For the *.F90 generated files, one could achieve it by making sure
the *r16* files are compiled with -mabi=ibmlongdouble, for
*r16i* or *r17* with -mabi=ieeelongdouble and otherwise use kind=16 in
those, for *.c generated files the *GFC_* macros could just ensure that
it doesn't use long double but __ibm128 or __float128 depending on which one
is needed.
But then I see e.g. the io routines to just pass in kind and so
switch (kind) // or len
  {
  case ...:
    *(GFC_REAL_*) = ...;
  }
etc.  Could we just pretend in the compiler to libgfortran ABI that
powerpc64le-linux real(kind=16) is kind 17 and make sure that if anything
would actually think it is 17 bytes it uses 16 instead (though, kind=10
on x86-64 or i686 also isn't 10 bytes but 16 or 12, right?).

Your thoughts on this?

	Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Richard Biener]

On Mon, Oct 4, 2021 at 12:08 PM Jakub Jelinek via Fortran
<fortran@gcc.gnu.org> wrote:
>
> Hi!
>
> On powerpc64le-linux target, one can select between two incompatible
> long double formats (both of them are 16-byte), __ibm128 which is
> a sum of two doubles, and __float128 (note, not implemented through
> libquadmath), which is IEEE754 quad format.  The default for
> long double can be selected with --with-long-double-format={ieee,ibm}
> configure options.
> AFAIK no distributions switched to --with-long-double-format=ieee
> yet (correct me if I'm wrong), but the goal is that eventually all
> distros switch to that (like they've switched from the --with-long-double-64
> default to --with-long-double-128 on powerpc64-linux, s390*-linux etc. years
> ago).
>
> libstdc++ has been changed already last year, so that the same
> libstdc++.so.6 is ABI compatible with both configurations, in C++ the
> IEEE quad long double mangles differently from IBM double double long
> double and so it is possible (with quite some work) to achieve that.
> Other C++ libraries not shipped as part of gcc are either lucky and don't
> use long double on any of its public APIs, then they are compatible with
> both, or developers can go the same painful way and support both ABIs in
> the same shared library, or they are simply ABI incompatible.
>
> But, I believe --with-long-double-format={ieee,ibm} configure time choice
> doesn't change just the meaning of long double, but also of real(kind=16)
> and complex(kind=32), but Fortran name mangling just appends _ and doesn't
> encode types.
> So, the choices for libgfortran.so.5 are either don't do anything, then
> we have from GCC the same SONAME but based on what --with-long-double-format={ieee,ibm}
> distributions choose ABI incompatible libraries, or bump libgfortran
> SONAME in GCC 12 on all targets (the problem is that it unnecessarily
> changes the SONAME even on targets that don't really need it - unless
> there are important ABI changes in the queue for GCC 12 already), but
> that to be effective would basically require that all distros change to
> --with-long-double-format=ieee together with GCC 12, or change the
> SONAME only on powerpc64le somehow (still the problem that all distros
> have to change at once), or add some kind=16 suffix letter into the SONAME
> if configured --with-long-double-format=ieee (so we'd have
> libgfortran.so.5ieee or whatever, and when we'd bump to libgfortran.so.6
> on all arches libgfortran.so.6ieee etc.).
>
> Or the last option would be to try to make libgfortran.so.5 ABI compatible
> with both choices on powerpc64le-linux.  From quick skimming of libgfortran,
> we have lots of generated functions, which use HAVE_GFC_REAL_16 and
> GFC_REAL_16 etc. macros.  So, we could perhaps arrange for the compiler
> to use r16i or r17 instead of r16 in the names when real(kind=16) is the
> IEEE quad on powerpc64le and keep using r16 for the IBM double double.
> For the *.F90 generated files, one could achieve it by making sure
> the *r16* files are compiled with -mabi=ibmlongdouble, for
> *r16i* or *r17* with -mabi=ieeelongdouble and otherwise use kind=16 in
> those, for *.c generated files the *GFC_* macros could just ensure that
> it doesn't use long double but __ibm128 or __float128 depending on which one
> is needed.
> But then I see e.g. the io routines to just pass in kind and so
> switch (kind) // or len
>   {
>   case ...:
>     *(GFC_REAL_*) = ...;
>   }
> etc.  Could we just pretend in the compiler to libgfortran ABI that
> powerpc64le-linux real(kind=16) is kind 17 and make sure that if anything
> would actually think it is 17 bytes it uses 16 instead (though, kind=10
> on x86-64 or i686 also isn't 10 bytes but 16 or 12, right?).
>
> Your thoughts on this?

How does glibc deal with this?  There's a load of long double ABI in there.

Richard.

>
>         Jakub
>

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek]

On Mon, Oct 04, 2021 at 01:24:05PM +0200, Richard Biener wrote:
> > Your thoughts on this?
> 
> How does glibc deal with this?  There's a load of long double ABI in there.

I don't know, CCing Florian; all I can see is that starting with glibc 2.26
in addition to sin{f,,l} there is also sinf128, but dunno if glibc headers
transparently map sinl to sinf128 or something else for the IEEE quad long
double or what.  But I believe glibc is like libstdc++ in that the same
libc.so.6 is ABI compatible with both ABIs (well, also the one where
long double is double, in that case I think glibc headers transparently
remap sinl to sin etc.).

	Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek]

On Mon, Oct 04, 2021 at 01:36:56PM +0200, Jakub Jelinek via Gcc wrote:
> On Mon, Oct 04, 2021 at 01:24:05PM +0200, Richard Biener wrote:
> > > Your thoughts on this?
> > 
> > How does glibc deal with this?  There's a load of long double ABI in there.
> 
> I don't know, CCing Florian; all I can see is that starting with glibc 2.26
> in addition to sin{f,,l} there is also sinf128, but dunno if glibc headers
> transparently map sinl to sinf128 or something else for the IEEE quad long
> double or what.  But I believe glibc is like libstdc++ in that the same
> libc.so.6 is ABI compatible with both ABIs (well, also the one where
> long double is double, in that case I think glibc headers transparently
> remap sinl to sin etc.).

Carlos said it is the __LDOUBLE_REDIRECTS_TO_FLOAT128_ABI == 1 stuff in
math.h etc., so I expect it is actually sinl -> __sinieee128 redirection
(using extern long double sinl (long double) __asm ("__sinieee128"); or so,
but through a lot of preprocessor macros).

	Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek]

On Mon, Oct 04, 2021 at 12:07:54PM +0200, Jakub Jelinek via Gcc wrote:
> Or the last option would be to try to make libgfortran.so.5 ABI compatible
> with both choices on powerpc64le-linux.  From quick skimming of libgfortran,
> we have lots of generated functions, which use HAVE_GFC_REAL_16 and
> GFC_REAL_16 etc. macros.  So, we could perhaps arrange for the compiler
> to use r16i or r17 instead of r16 in the names when real(kind=16) is the
> IEEE quad on powerpc64le and keep using r16 for the IBM double double.
> For the *.F90 generated files, one could achieve it by making sure
> the *r16* files are compiled with -mabi=ibmlongdouble, for
> *r16i* or *r17* with -mabi=ieeelongdouble and otherwise use kind=16 in
> those, for *.c generated files the *GFC_* macros could just ensure that
> it doesn't use long double but __ibm128 or __float128 depending on which one
> is needed.
> But then I see e.g. the io routines to just pass in kind and so
> switch (kind) // or len
>   {
>   case ...:
>     *(GFC_REAL_*) = ...;
>   }
> etc.  Could we just pretend in the compiler to libgfortran ABI that
> powerpc64le-linux real(kind=16) is kind 17 and make sure that if anything
> would actually think it is 17 bytes it uses 16 instead (though, kind=10
> on x86-64 or i686 also isn't 10 bytes but 16 or 12, right?).
> 
> Your thoughts on this?

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.
libgfortran would then on powerpc64le-linux use -mabi=ieeelongdouble to make
sure that regardless of the long double choice for C/C++ (whether default
configure time selection or explicit -mabi=*) GFC_REAL_16 is the __float128
long double.
One problem with that is that I think IEEE quad long double support relies
on glibc 2.32 or later, so not sure what exactly would be done if gcc is
built against older glibc when it needs to call libm routines.  Perhaps
convert to __ibm128, call the __ibm128 sinl etc. and convert back (big loss
of precision and range, but at least something).

What does libstdc++ do there?

	Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Mon, 4 Oct 2021, Jakub Jelinek via Gcc wrote:

> One problem with that is that I think IEEE quad long double support relies
> on glibc 2.32 or later, so not sure what exactly would be done if gcc is
> built against older glibc when it needs to call libm routines.  Perhaps
> convert to __ibm128, call the __ibm128 sinl etc. and convert back (big loss
> of precision and range, but at least something).

Using libquadmath functions would be better in that case - arranging for 
libquadmath to be built in this case if it isn't already - than converting 
to __ibm128.

(On the other hand, when _Float128 functions are available in libm, I 
think it would be better for Fortran to call those rather than libquadmath 
functions - *f128 (or the __*ieee128 aliases available on powerpc64le for 
namespace reasons, not sure if those namespace reasons have any relevance 
to Fortran) instead of *q.  See my comments on that in 
<https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578937.html>.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

Hi!

On Mon, Oct 04, 2021 at 04:14:10PM +0200, Jakub Jelinek 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.
> libgfortran would then on powerpc64le-linux use -mabi=ieeelongdouble to make
> sure that regardless of the long double choice for C/C++ (whether default
> configure time selection or explicit -mabi=*) GFC_REAL_16 is the __float128
> long double.
> One problem with that is that I think IEEE quad long double support relies
> on glibc 2.32 or later, so not sure what exactly would be done if gcc is
> built against older glibc when it needs to call libm routines.  Perhaps
> convert to __ibm128, call the __ibm128 sinl etc. and convert back (big loss
> of precision and range, but at least something).

Eventually we should get a world where kind=16 is IEEE QP float
everywhere, and kind=17 (or whatever) is double-double.

Some current Power GCC targets support neither.  Some support only
double-double.  Making IEEE QP float work on those (that is, those that
are < power8) will require some work still: it should use libquadmath or
similar, but that needs to be put into the ABIs, to define how parameter
passing works for those types.  Just treating it like a struct or an
array of ints will work fine, but it needs to be written down.  This is
more than just Fortran.

Mike?


Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Mon, 4 Oct 2021, Segher Boessenkool wrote:

> Some current Power GCC targets support neither.  Some support only
> double-double.  Making IEEE QP float work on those (that is, those that
> are < power8) will require some work still: it should use libquadmath or
> similar, but that needs to be put into the ABIs, to define how parameter
> passing works for those types.  Just treating it like a struct or an
> array of ints will work fine, but it needs to be written down.  This is
> more than just Fortran.

Is the 64-bit BE (ELFv1) ABI maintained somewhere?  (The 32-bit ABI, 
covering both hard float and soft float, is 
<https://github.com/ryanarn/powerabi> - no activity lately, but I think 
Ryan said he'd given write access to someone still involved with Power.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

Hi Joseph,

On Mon, Oct 04, 2021 at 07:24:31PM +0000, Joseph Myers wrote:
> On Mon, 4 Oct 2021, Segher Boessenkool wrote:
> > Some current Power GCC targets support neither.  Some support only
> > double-double.  Making IEEE QP float work on those (that is, those that
> > are < power8) will require some work still: it should use libquadmath or
> > similar, but that needs to be put into the ABIs, to define how parameter
> > passing works for those types.  Just treating it like a struct or an
> > array of ints will work fine, but it needs to be written down.  This is
> > more than just Fortran.
> 
> Is the 64-bit BE (ELFv1) ABI maintained somewhere?  (The 32-bit ABI, 
> covering both hard float and soft float, is 
> <https://github.com/ryanarn/powerabi> - no activity lately, but I think 
> Ryan said he'd given write access to someone still involved with Power.)

The last release (version 1.9) was in 2004.  If there is interest in
making updates to it that coulde be done of course, it is GFDL, there is
no red tape getting in the way.

Maybe this could be maintained in the same repository even?


Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Bill Schmidt]

On 10/5/21 12:43 PM, Segher Boessenkool wrote:
> Hi Joseph,
>
> On Mon, Oct 04, 2021 at 07:24:31PM +0000, Joseph Myers wrote:
>> On Mon, 4 Oct 2021, Segher Boessenkool wrote:
>>> Some current Power GCC targets support neither.  Some support only
>>> double-double.  Making IEEE QP float work on those (that is, those that
>>> are < power8) will require some work still: it should use libquadmath or
>>> similar, but that needs to be put into the ABIs, to define how parameter
>>> passing works for those types.  Just treating it like a struct or an
>>> array of ints will work fine, but it needs to be written down.  This is
>>> more than just Fortran.
>> Is the 64-bit BE (ELFv1) ABI maintained somewhere?  (The 32-bit ABI, 
>> covering both hard float and soft float, is 
>> <https://github.com/ryanarn/powerabi> - no activity lately, but I think 
>> Ryan said he'd given write access to someone still involved with Power.)

Just FYI, that person is me.  I've never tried to use my powers, either for good
or evil, since no proposals for updates have arisen since Ryan left; but my
credentials should still work.

> The last release (version 1.9) was in 2004.  If there is interest in
> making updates to it that coulde be done of course, it is GFDL, there is
> no red tape getting in the way.
>
> Maybe this could be maintained in the same repository even?

Well, I'm not sure it's quite this easy; when developing ELFv2, there was enough
doubt about the provenance/ownership of ELFv1 that we weren't comfortable borrowing
language from it.  That may have been an excess of caution, or it may not...

That said, with enough diligence I would hope we would be able to create
modifications to the ELFv1 document, but we might incur some paperwork.

Bill

>
>
> Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

On Thu, Oct 14, 2021 at 02:39:47PM -0500, Bill Schmidt wrote:
> On 10/5/21 12:43 PM, Segher Boessenkool wrote:
> > The last release (version 1.9) was in 2004.  If there is interest in
> > making updates to it that coulde be done of course, it is GFDL, there is
> > no red tape getting in the way.
> >
> > Maybe this could be maintained in the same repository even?
> 
> Well, I'm not sure it's quite this easy; when developing ELFv2, there was enough
> doubt about the provenance/ownership of ELFv1 that we weren't comfortable borrowing
> language from it.  That may have been an excess of caution, or it may not...

I am not suggesting you should share this text with some other ABI.
Just that you can put it in the same repository :-)

> That said, with enough diligence I would hope we would be able to create
> modifications to the ELFv1 document, but we might incur some paperwork.

It is GFDL version 1.1 .  The hardest part should be to find that older
licence version :-P
(<https://www.gnu.org/licenses/old-licenses/fdl-1.1.en.html> fwiw)

(But I understand your situation, heh.  Let the lawyers worry about it?
That is their job :-) )


Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Thomas Koenig]

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

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.

Hmm...

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

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.

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.

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.

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.


Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Thomas Koenig]

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

Re: 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

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek]

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.

But only for Power8 or later, no?  I guess the reason why le can switch
moreless easily (well, far from it, it is terribly hard anyway) is that
power8 is the oldest supported ISA for le, while be can't really assume
power8 or later.
Also, seems e.g. glibc support is there only for ppc64le and not be:
find . -name libm.abilist | xargs grep sinieee128
./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 __asinieee128 F
./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 __casinieee128 F
./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 __csinieee128 F
./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 __sinieee128 F

	Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

On Wed, Oct 06, 2021 at 05:41:07PM +0200, Jakub Jelinek 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:
> > > >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.
> 
> But only for Power8 or later, no?  I guess the reason why le can switch
> moreless easily (well, far from it, it is terribly hard anyway) is that
> power8 is the oldest supported ISA for le, while be can't really assume
> power8 or later.

Yes.

We can emulate it everywhere (using libquadmath for example).  This can
magically make -msoft-float work as well everywhere, btw.

> Also, seems e.g. glibc support is there only for ppc64le and not be:
> find . -name libm.abilist | xargs grep sinieee128
> ./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 __asinieee128 F
> ./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 __casinieee128 F
> ./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 __csinieee128 F
> ./sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libm.abilist:GLIBC_2.32 __sinieee128 F

I don't know what the glibc situation is.  The libraries will naturally
not invest their energy in making anything work if the compiler neglects
it :-(


Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek]

On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> We can emulate it everywhere (using libquadmath for example).  This can
> magically make -msoft-float work as well everywhere, btw.

Emulation is one thing, but another one is where are those __float128 or
quad long double arguments and return values passed.  On power8 le I think
they are passed in VSX registers, aren't they?
But are those available everywhere where ppc64 is supported?  For ppc32
certainly not, I don't remember for ppc64.
Sure, the ABI could say pass it in e.g. in a pair of integer registers...

	Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > We can emulate it everywhere (using libquadmath for example).  This can
> > magically make -msoft-float work as well everywhere, btw.
> 
> Emulation is one thing, but another one is where are those __float128 or
> quad long double arguments and return values passed.  On power8 le I think
> they are passed in VSX registers, aren't they?

On BE just as well.  And on 32 bit.

> But are those available everywhere where ppc64 is supported?  For ppc32
> certainly not, I don't remember for ppc64.

You can use VSX registers on 32 bit just fine.

> Sure, the ABI could say pass it in e.g. in a pair of integer registers...

Or more, on 32-bit.  It isn't very useful to try to optimise this, so
it is easiest to just handle it the same as a struct for register
passing.  For 32-bit this means it then is passed and returned as a
pointer, for the older 64-bit ABIs it means it is passed as two GPRs but
returned as a pointer, and for the ELFv2 ABI (on both BE and LE) it
means that it is passed as well as returned in two GPRs.


Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek]

On Wed, Oct 06, 2021 at 11:59:37AM -0500, Segher Boessenkool wrote:
> On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote:
> > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > > We can emulate it everywhere (using libquadmath for example).  This can
> > > magically make -msoft-float work as well everywhere, btw.
> > 
> > Emulation is one thing, but another one is where are those __float128 or
> > quad long double arguments and return values passed.  On power8 le I think
> > they are passed in VSX registers, aren't they?
> 
> On BE just as well.  And on 32 bit.
> 
> > But are those available everywhere where ppc64 is supported?  For ppc32
> > certainly not, I don't remember for ppc64.
> 
> You can use VSX registers on 32 bit just fine.

With -mvsx (or perhaps even -maltivec) sure, but if neither VSX nor Altivec
ISA is there...
And having the ABI for long double dependent on whether one uses
-mvsx/-maltivec or not is a non-started.  For generic vectors it is
something we decided to be acceptable...

	Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

On Wed, Oct 06, 2021 at 07:07:43PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 06, 2021 at 11:59:37AM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote:
> > > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > > > We can emulate it everywhere (using libquadmath for example).  This can
> > > > magically make -msoft-float work as well everywhere, btw.
> > > 
> > > Emulation is one thing, but another one is where are those __float128 or
> > > quad long double arguments and return values passed.  On power8 le I think
> > > they are passed in VSX registers, aren't they?
> > 
> > On BE just as well.  And on 32 bit.
> > 
> > > But are those available everywhere where ppc64 is supported?  For ppc32
> > > certainly not, I don't remember for ppc64.
> > 
> > You can use VSX registers on 32 bit just fine.
> 
> With -mvsx (or perhaps even -maltivec) sure, but if neither VSX nor Altivec
> ISA is there...

This was for -mcpu=power8 only.  And yes, you can use -mno-vsx if you
have p8 or later, which gives us the same issues as -msoft-float.

> And having the ABI for long double dependent on whether one uses
> -mvsx/-maltivec or not is a non-started.  For generic vectors it is
> something we decided to be acceptable...

This is not about long double.  This is about IEEE quad precision float.
We need to make that work (on system X) before we can fathom using IEEE
QP float as long double on system X.

Working out what the parameter passing should be like is independent of
what type is used for long double.

-msoft-float has been a separate ABI always, of course.  And so far QP
float has not existed for powerpc64-linux.

So we have three options (well, four):

0) Do nothing.  We will stay in this hell forever.  Not my choice :-)
1) Use a soft-float-like parameter passing everywhere.  This works but
   will be horridly slow on newer systems.  We can do better than that.
2) Use the current setup where -mcpu=power8 (or later) makes QP float
   available.  Most BE stuff isn't compiled with that currently, and it
   will split our ecosystem.
3) As Joseph reminds me the high VSRs are the VRs, so we could use the
   same parameter passing on anything with AltiVec.  We could even
   simply require -maltivec for QP float to be supported (we currently
   require -mvsx, this would not be a restriction).

I think I like 3) :-)


Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Peter Bergner]

On 10/6/21 12:50 PM, Segher Boessenkool wrote:
> So we have three options (well, four):
> 
> 0) Do nothing.  We will stay in this hell forever.  Not my choice :-)
> 1) Use a soft-float-like parameter passing everywhere.  This works but
>    will be horridly slow on newer systems.  We can do better than that.
> 2) Use the current setup where -mcpu=power8 (or later) makes QP float
>    available.  Most BE stuff isn't compiled with that currently, and it
>    will split our ecosystem.
> 3) As Joseph reminds me the high VSRs are the VRs, so we could use the
>    same parameter passing on anything with AltiVec.  We could even
>    simply require -maltivec for QP float to be supported (we currently
>    require -mvsx, this would not be a restriction).
> 
> I think I like 3) :-)

I like 3 too, meaning requiring -maltivec to support IEEE QP at all.
This would cover POWER6 and later server CPUs, as well as some other
cpus like in the Power Macs.  

Anything without Altivec hardware would need to either not support
IEEE QP at all, or go through the work themselves of coming up with
a -msoft-altivec like ABI.

Peter

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Wed, 6 Oct 2021, Jakub Jelinek via Gcc wrote:

> On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > We can emulate it everywhere (using libquadmath for example).  This can
> > magically make -msoft-float work as well everywhere, btw.
> 
> Emulation is one thing, but another one is where are those __float128 or
> quad long double arguments and return values passed.  On power8 le I think
> they are passed in VSX registers, aren't they?
> But are those available everywhere where ppc64 is supported?  For ppc32
> certainly not, I don't remember for ppc64.

As noted in previous discussions, while the current GCC implementation 
requires VSX for _Float128 support, the registers used in the ABI are the 
same as AltiVec registers; it would be possible to implement support for 
_Float128 on all powerpc64 with AltiVec (most but not all 64-bit 
processors), using AltiVec registers in the ABI and being fully compatible 
with the ABI using VSX registers.

> Sure, the ABI could say pass it in e.g. in a pair of integer registers...

You'd need to decide whether you want the 64-bit BE ABI for _Float128 to 
be one that supports the type on all 64-bit processors (so pass in integer 
registers), or one that only supports it on processors with AltiVec but is 
more similar to the LE ABI (passing in AltiVec registers).

And, then, decide the 32-bit ABIs (hard and soft float), if you want to 
support _Float128 there.

And, then, do glibc changes, both to support _Float128 functions at all, 
and to support a different long double format if you wish to support 
changing the long double format for those ABIs.  Note that the symbol 
versioning in glibc assumes that all libm functions either predate 
_Float128 support on all architectures (version of *f128 versions is 
FLOAT128_VERSION) or postdate it on all architectures (versions in 
math/Versions based on whenever that function was added to glibc; various 
*f64x functions, that alias *f128 when appropriate, are also hardcoded as 
GLIBC_2.27).  So if someone adds _Float128 support to any glibc ABI that 
doesn't currently have it, they need to add support for new syntax in 
Versions files such as MAX (FLOAT128_VERSION, GLIBC_2.28), which describes 
the right symbol version for a _Float128 function added in 2.28, in the 
case where some architecture gets _Float128 support later than that.  And 
likewise using LDBL_IBM128_VERSION for __*ieee128 aliases if you add 
support for it being used as a new long double format.  And adding the 
support to glibc means increasing the minimum GCC version for building 
glibc for those ABIs to one that supports _Float128 for those ABIs.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

On Wed, Oct 06, 2021 at 05:13:59PM +0000, Joseph Myers wrote:
> On Wed, 6 Oct 2021, Jakub Jelinek via Gcc wrote:
> > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > > We can emulate it everywhere (using libquadmath for example).  This can
> > > magically make -msoft-float work as well everywhere, btw.
> > 
> > Emulation is one thing, but another one is where are those __float128 or
> > quad long double arguments and return values passed.  On power8 le I think
> > they are passed in VSX registers, aren't they?
> > But are those available everywhere where ppc64 is supported?  For ppc32
> > certainly not, I don't remember for ppc64.
> 
> As noted in previous discussions, while the current GCC implementation 
> requires VSX for _Float128 support, the registers used in the ABI are the 
> same as AltiVec registers; it would be possible to implement support for 
> _Float128 on all powerpc64 with AltiVec (most but not all 64-bit 
> processors), using AltiVec registers in the ABI and being fully compatible 
> with the ABI using VSX registers.

Good point.  And we can simply require -maltivec for -mfloat128 to work.
We currently require -mvsx, which itself requires -maltivec, so that is
not a restriction.

> > Sure, the ABI could say pass it in e.g. in a pair of integer registers...
> 
> You'd need to decide whether you want the 64-bit BE ABI for _Float128 to 
> be one that supports the type on all 64-bit processors (so pass in integer 
> registers), or one that only supports it on processors with AltiVec but is 
> more similar to the LE ABI (passing in AltiVec registers).

I vote for the latter: require -maltivec.  Well unless -msoft-float
perhaps, if someone ever cares enough to implement that for QP float :-)

> And, then, decide the 32-bit ABIs (hard and soft float), if you want to 
> support _Float128 there.

Soft float is not described in any formal ABI btw (well, except the
Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair.
Which does not work over function calls, but that is how it always has
been.

This never was a huge problem afaik.

For 32-bit, maybe we can just require -maltivec as well, to allow
-mfloat128?  Or use what -msoft-float would do for _Float128, if
-mno-altivec, if desired (this does not have to be limited to -m32 of
course).

> And, then, do glibc changes, both to support _Float128 functions at all, 
> and to support a different long double format if you wish to support 
> changing the long double format for those ABIs.  Note that the symbol 
> versioning in glibc assumes that all libm functions either predate 
> _Float128 support on all architectures (version of *f128 versions is 
> FLOAT128_VERSION) or postdate it on all architectures (versions in 
> math/Versions based on whenever that function was added to glibc; various 
> *f64x functions, that alias *f128 when appropriate, are also hardcoded as 
> GLIBC_2.27).  So if someone adds _Float128 support to any glibc ABI that 
> doesn't currently have it, they need to add support for new syntax in 
> Versions files such as MAX (FLOAT128_VERSION, GLIBC_2.28), which describes 
> the right symbol version for a _Float128 function added in 2.28, in the 
> case where some architecture gets _Float128 support later than that.  And 
> likewise using LDBL_IBM128_VERSION for __*ieee128 aliases if you add 
> support for it being used as a new long double format.  And adding the 
> support to glibc means increasing the minimum GCC version for building 
> glibc for those ABIs to one that supports _Float128 for those ABIs.

Glibc is outside of my direct influence sphere ;-)  This does sound like
a reasonable plan to me though.


Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Wed, 6 Oct 2021, Segher Boessenkool wrote:

> Soft float is not described in any formal ABI btw (well, except the
> Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair.

It's fully documented in the unified 32-bit ABI document (under 
ATR-SOFT-FLOAT conditionals).

There's still some code in the compiler for a very old soft-float ABI for 
binary128 long double (passing by reference, using _q_* libcall names).  I 
don't really think it makes much sense to use that for future _Float128 
support for soft-float (certainly not the _q_* libcalls), rather than 
passing in four consecutive GPRs as is done for IBM long double for soft 
float, but we could.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 1697 bytes --]

On Wed, Oct 06, 2021 at 07:42:31PM +0000, Joseph Myers wrote:
> On Wed, 6 Oct 2021, Segher Boessenkool wrote:
> > Soft float is not described in any formal ABI btw (well, except the
> > Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair.
> 
> It's fully documented in the unified 32-bit ABI document (under 
> ATR-SOFT-FLOAT conditionals).

That doc calls itself "Power Architecture® 32-bit Application Binary
Interface Supplement 1.0 - Embedded".  That is the exception I meant.
Ignoring all the stuff I usually ignore it isn't very embedded, I agree,
it is more or less what is powerpc-linux or powerpc-elf.

With "not in any" I mean: not for other architectures either!  All archs
that do not say anything about floating point in their machine
description get a working sofware floating point (for binary32 and
binary64 currently).

> There's still some code in the compiler for a very old soft-float ABI for 
> binary128 long double (passing by reference, using _q_* libcall names).  I 
> don't really think it makes much sense to use that for future _Float128 
> support for soft-float (certainly not the _q_* libcalls), rather than 
> passing in four consecutive GPRs as is done for IBM long double for soft 
> float, but we could.

Maybe this harks back to POWER2 days?  If so, we probably should just
remove that code, we do not support anything else POWER2 anymore.


If we want to implement soft-float for binary128, it would be best to do
it the same for Power as for anything else.  That of course means we
have to *do* it for everything (or anything) else :-)

And, as long as I'm creating more work, we could do binary16 and
bfloat16 at the same time ;-)


Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Wed, 6 Oct 2021, Segher Boessenkool wrote:

> > There's still some code in the compiler for a very old soft-float ABI for 
> > binary128 long double (passing by reference, using _q_* libcall names).  I 
> > don't really think it makes much sense to use that for future _Float128 
> > support for soft-float (certainly not the _q_* libcalls), rather than 
> > passing in four consecutive GPRs as is done for IBM long double for soft 
> > float, but we could.
> 
> Maybe this harks back to POWER2 days?  If so, we probably should just
> remove that code, we do not support anything else POWER2 anymore.

The _q_* names and associated ABI are in the 1995 SunSoft PowerPC ABI 
(which I suppose was the ABI for PowerPC Solaris).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Wed, 6 Oct 2021, Segher Boessenkool wrote:

> With "not in any" I mean: not for other architectures either!  All archs
> that do not say anything about floating point in their machine
> description get a working sofware floating point (for binary32 and
> binary64 currently).

Any architecture that supports a software floating-point ABI (i.e. one 
that does argument passing and return for floating-point in integer 
registers) should specify it in its ABI documents.  For example, 
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc 
describes both "Integer Calling Convention" and "Hardware Floating-point 
Calling Convention", with a series of named ABIs based on those such as 
LP64, LP64F, etc. (like on (32-bit) Arm, but unlike Power or MIPS, RISC-V 
GCC also supports building programs that use hardware floating-point 
instructions but the software floating-point ABI).

That's how the (unified) 32-bit powerpc ABI documents things: both 
hardware and software floating-point ABI variants.

If the architecture doesn't support hardware floating point, or doesn't 
have separate registers for it, the software floating-point ABI is just 
"the ABI" and there's no separate hardware floating-point ABI, of course.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

On Wed, Oct 06, 2021 at 10:03:59PM +0000, Joseph Myers wrote:
> On Wed, 6 Oct 2021, Segher Boessenkool wrote:
> > With "not in any" I mean: not for other architectures either!  All archs
> > that do not say anything about floating point in their machine
> > description get a working sofware floating point (for binary32 and
> > binary64 currently).
> 
> Any architecture that supports a software floating-point ABI (i.e. one 
> that does argument passing and return for floating-point in integer 
> registers) should specify it in its ABI documents.  For example, 
> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc 
> describes both "Integer Calling Convention" and "Hardware Floating-point 
> Calling Convention", with a series of named ABIs based on those such as 
> LP64, LP64F, etc. (like on (32-bit) Arm, but unlike Power or MIPS, RISC-V 
> GCC also supports building programs that use hardware floating-point 
> instructions but the software floating-point ABI).

But many CPUs do not have hardware floating point in any variant, and
their ABIs / calling conventions do not mention floating point at all.
Still, this works with GCC just fine: it passes floats and doubles the
same as 32-bit resp. 64-bit integers.

binary16 and bfloat16 would be easy to support the same way, but it is a
bit harder for binary128, because we do not have a 128-bit integer type
on all systems.  That should be fixed first probably.  It doesn't have
to be very good machine code, but having it supported everywhere would
simplify things a lot.

> That's how the (unified) 32-bit powerpc ABI documents things: both 
> hardware and software floating-point ABI variants.

Yes.  I am not saying this isn't good or desirable, but simply how
things are now.

> If the architecture doesn't support hardware floating point, or doesn't 
> have separate registers for it, the software floating-point ABI is just 
> "the ABI" and there's no separate hardware floating-point ABI, of course.

Right, and many architectures neglect to even mention anything to do
with floating point, although this is and always was a standard C
feature :-/


Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Fri, 8 Oct 2021, Segher Boessenkool wrote:

> But many CPUs do not have hardware floating point in any variant, and
> their ABIs / calling conventions do not mention floating point at all.
> Still, this works with GCC just fine: it passes floats and doubles the
> same as 32-bit resp. 64-bit integers.
> 
> binary16 and bfloat16 would be easy to support the same way, but it is a
> bit harder for binary128, because we do not have a 128-bit integer type

Supporting passing arguments (and return values) the same as an integer 
type of the same size is a *choice* (which comes with other choices - in 
particular, whether to say some or all the higher bits in the register or 
stack slot are sign-extended, zero-extended or undefined).  It's a choice 
that should be made explicitly, and documented (in the relevant ABI if one 
is maintained), and coordinated between implementations when there's more 
than one implementation for the architecture trying to be compatible.  
We've had plenty of problems in the past with ABIs that were just what 
happened to fall out of the implementation (e.g. ABIs that depended on the 
details of what machine mode was assigned to a structure type...).

On a related note, I'd encourage architecture maintainers to start 
thinking now about what exactly their ABIs should be for _BitInt 
(<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf>, accepted as 
a required feature for C23 up to at least the width of unsigned long 
long), and documenting it and coordinating with other implementations 
where appropriate.  There's a concrete proposal for x86_64 (see 
origin/usr/hjl/bitint branch at 
https://gitlab.com/x86-psABIs/x86-64-ABI.git) that may at least help as an 
indication of the sort of issues to address in such an ABI.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

Hi!

On Mon, Oct 11, 2021 at 08:11:50PM +0000, Joseph Myers wrote:
> On Fri, 8 Oct 2021, Segher Boessenkool wrote:
> > But many CPUs do not have hardware floating point in any variant, and
> > their ABIs / calling conventions do not mention floating point at all.
> > Still, this works with GCC just fine: it passes floats and doubles the
> > same as 32-bit resp. 64-bit integers.
> > 
> > binary16 and bfloat16 would be easy to support the same way, but it is a
> > bit harder for binary128, because we do not have a 128-bit integer type
> 
> Supporting passing arguments (and return values) the same as an integer 
> type of the same size is a *choice* (which comes with other choices - in 
> particular, whether to say some or all the higher bits in the register or 
> stack slot are sign-extended, zero-extended or undefined).  It's a choice 
> that should be made explicitly, and documented (in the relevant ABI if one 
> is maintained), and coordinated between implementations when there's more 
> than one implementation for the architecture trying to be compatible.  

I don't disagree at all.  But: GCC makes that choice for you, if you do
not.  Many (embedded and/or older) targets do not.  They get the
defaults, those just work, and /de facto/ become the standard.

In practice most such architectures are purely 32-bit, so there is no
sign/zero extension problem.

> We've had plenty of problems in the past with ABIs that were just what 
> happened to fall out of the implementation (e.g. ABIs that depended on the 
> details of what machine mode was assigned to a structure type...).

Yes.

And we still have problems on older ABIs with e.g. new C++ requirements
that did not exist >25 years ago when the ABIs were written.  Not all of
this can be helped at all.

> On a related note, I'd encourage architecture maintainers to start 
> thinking now about what exactly their ABIs should be for _BitInt 
> (<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf>, accepted as 
> a required feature for C23 up to at least the width of unsigned long 
> long), and documenting it and coordinating with other implementations 
> where appropriate.  There's a concrete proposal for x86_64 (see 
> origin/usr/hjl/bitint branch at 
> https://gitlab.com/x86-psABIs/x86-64-ABI.git) that may at least help as an 
> indication of the sort of issues to address in such an ABI.

This should really go on gcc@, in a thread of its own, and a wiki page
might help as well?


Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[David Edelsohn]

On Wed, Oct 6, 2021 at 11:19 AM Segher Boessenkool
<segher@kernel.crashing.org> 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.

This needs to be described with more granularity.  IEEE QP
instructions work with either endianness.

IEEE QP is enabled and supported for PPC64 LE Linux on Power.  The
transition is under discussion.

PPC64 BE Linux on Power does not define IEEE QP.  The ABI could be
updated and IEEE QP could be enabled, but PPC64 BE is not planning
future releases from Linux distros.

IEEE QP for PPC64 FreeBSD on Power is an open question for the FreeBSD
community.

AIX on Power will continue to use double-double long double format.
GCC, LLVM, IBM Open XL and IBM XL compilers will continue to implement
and support the double-double format on AIX.

Thanks, David

P.S. This is my personal understanding and not an official statement
of support or product guidance from IBM.

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

On Wed, Oct 06, 2021 at 11:42:17AM -0400, David Edelsohn wrote:
> On Wed, Oct 6, 2021 at 11:19 AM Segher Boessenkool
> <segher@kernel.crashing.org> 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.
> 
> This needs to be described with more granularity.  IEEE QP
> instructions work with either endianness.
> 
> IEEE QP is enabled and supported for PPC64 LE Linux on Power.  The
> transition is under discussion.

IEEE QP insns are enabled for BE as well:

powerpc64-linux-gcc -Wall -W -O2 -S qp.c -mcpu=power9

=== qp.c ===
#define QP _Float128
QP f(QP x) { return x*x; }
===

results in

.L.f:
        xsmulqp 2,2,2
        blr

> PPC64 BE Linux on Power does not define IEEE QP.  The ABI could be
> updated and IEEE QP could be enabled, but PPC64 BE is not planning
> future releases from Linux distros.

This is a different thing: on BE (and on LE by default as well) we use
double-double for long double.

> IEEE QP for PPC64 FreeBSD on Power is an open question for the FreeBSD
> community.

Yes.

> AIX on Power will continue to use double-double long double format.
> GCC, LLVM, IBM Open XL and IBM XL compilers will continue to implement
> and support the double-double format on AIX.

Yes.  But this wasn't about what to use for long double -- it was about
Fortran even :-)

The actual IEEE QP float types work fine on BE.  I suspect they do on
AIX as well for that matter?

Fwiw, with -mcpu=power8 we get

.L.f:
        mflr 0
        xxlor 35,34,34
        std 0,16(1)
        stdu 1,-112(1)
        bl __mulkf3
        nop
        addi 1,1,112
        ld 0,16(1)
        mtlr 0
        blr


Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[David Edelsohn]

On Wed, Oct 6, 2021 at 12:21 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Wed, Oct 06, 2021 at 11:42:17AM -0400, David Edelsohn wrote:
> > On Wed, Oct 6, 2021 at 11:19 AM Segher Boessenkool
> > <segher@kernel.crashing.org> 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.
> >
> > This needs to be described with more granularity.  IEEE QP
> > instructions work with either endianness.
> >
> > IEEE QP is enabled and supported for PPC64 LE Linux on Power.  The
> > transition is under discussion.
>
> IEEE QP insns are enabled for BE as well:
>
> powerpc64-linux-gcc -Wall -W -O2 -S qp.c -mcpu=power9
>
> === qp.c ===
> #define QP _Float128
> QP f(QP x) { return x*x; }
> ===
>
> results in
>
> .L.f:
>         xsmulqp 2,2,2
>         blr
>
> > PPC64 BE Linux on Power does not define IEEE QP.  The ABI could be
> > updated and IEEE QP could be enabled, but PPC64 BE is not planning
> > future releases from Linux distros.
>
> This is a different thing: on BE (and on LE by default as well) we use
> double-double for long double.
>
> > IEEE QP for PPC64 FreeBSD on Power is an open question for the FreeBSD
> > community.
>
> Yes.
>
> > AIX on Power will continue to use double-double long double format.
> > GCC, LLVM, IBM Open XL and IBM XL compilers will continue to implement
> > and support the double-double format on AIX.
>
> Yes.  But this wasn't about what to use for long double -- it was about
> Fortran even :-)
>
> The actual IEEE QP float types work fine on BE.  I suspect they do on
> AIX as well for that matter?
>
> Fwiw, with -mcpu=power8 we get
>
> .L.f:
>         mflr 0
>         xxlor 35,34,34
>         std 0,16(1)
>         stdu 1,-112(1)
>         bl __mulkf3
>         nop
>         addi 1,1,112
>         ld 0,16(1)
>         mtlr 0
>         blr

GCC can generate the IEEE QP instructions on AIX.  The AIX Assembler
is aware of the instructions.  libquadmath is neither built nor
installed on AIX.  The AIX C library and AIX Math library are not
aware of the IEEE QP type nor how to work with it, e.g., printf.

Thanks, David

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Michael Meissner]

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.

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

If the code is compiled for power8, it always uses the software functions to do
the support.  Buried inside of libgcc are ifunc functions that use the hardware
instructions if the user is running on power9 or power10.  It would be nice if
any distro that changed the default used power9 as a base, instead of power8.

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

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: 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

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Alastair McKinstry]

On 06/10/2021 07:59, Thomas Koenig via Fortran wrote:
> 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.
>
I strongly advise against this -- identical SONAMEs for the libraries on 
all architectures is a key assumption on all Debian-based distributions 
and designs - I don't see it being possible on Fedora or SuSE etc either 
; all presume a library package and updates based on SONAME (ie each 
source only generates a single SONAME). Updating SONAMEs is a key tool 
for distributions.

Alastair

-- 
Alastair McKinstry, <alastair@sceal.ie>, <mckinstry@debian.org>, https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Andreas Schwab]

On Okt 07 2021, Alastair McKinstry wrote:

> I strongly advise against this -- identical SONAMEs for the libraries on
> all architectures is a key assumption on all Debian-based distributions 
> and designs

Even glibc has differing sonames on some architectures.  And libgcc_s,
too.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek]

On Thu, Oct 07, 2021 at 11:56:45AM +0200, Andreas Schwab wrote:
> On Okt 07 2021, Alastair McKinstry wrote:
> 
> > I strongly advise against this -- identical SONAMEs for the libraries on
> > all architectures is a key assumption on all Debian-based distributions 
> > and designs
> 
> Even glibc has differing sonames on some architectures.  And libgcc_s,
> too.

Yeah, lib[cm].so.6 on most arches and lib[cm].so.6.1 on ia64 or alpha.
At least on Fedora I don't see a problem having libgfortran.so.5 on
most arches and libgfortran.so.6 on ppc64le.  And then next year or two/3
switch to libgfortran.so.7 everywhere.

	Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Alastair McKinstry]

On 07/10/2021 11:01, Jakub Jelinek wrote:
> On Thu, Oct 07, 2021 at 11:56:45AM +0200, Andreas Schwab wrote:
>> On Okt 07 2021, Alastair McKinstry wrote:
>>
>>> I strongly advise against this -- identical SONAMEs for the libraries on
>>> all architectures is a key assumption on all Debian-based distributions
>>> and designs
>> Even glibc has differing sonames on some architectures.  And libgcc_s,
>> too.
> Yeah, lib[cm].so.6 on most arches and lib[cm].so.6.1 on ia64 or alpha.
> At least on Fedora I don't see a problem having libgfortran.so.5 on
> most arches and libgfortran.so.6 on ppc64le.  And then next year or two/3
> switch to libgfortran.so.7 everywhere.

SOVERSION (Major release) (and hence SONAME) change tracking are key to 
tracking the task of rebuilds/porting when incompatible changes happen 
in libraries

(see https://release.debian.org/transitions/ and 
https://wiki.debian.org/Teams/ReleaseTeam/Transitions for examples of 
the process).

lib[cm] on ia64 and alpha work in that libc has not changed major 
version in many years, and neither ia64 or alpha are currently "release 
candidates" in Debian, which we need to keep rebuilds in sync. Even so, 
the exception handling needed for them is a wart seen across the distro 
dependency trees.

To make upgrades work, we have policy that it's possible that two 
versions of a library with different SONAME can co-exist  on a users' 
system (package libgfortran5  "just" ships the libgfortran.so.5  file, 
libgfortran6 can co-exist with it), but a given source package only 
provides one of these library packages, and there is only one -dev 
package (eg libgfortran-dev pointing libgfortran.so -> libgfortan.so.6).

A transition (eg gcc-11 to gcc-12 moving into the 'testing' staging 
distro) updates libgfortran-dev to point to 6, drops libgfortran5 from 
the Debian archive (but doesn't delete the package libgfortran5 from the 
users' computer) and we rebuild and transition simultaneously all 
packages that depend on libgfortran5.

So if we introduce libgfortran6 for ppc64le (with potential ABI changes 
such as KIND) we rely on libgfortran5 disappearing for our transition 
scripts to work, and testing the transition process. We can special-case 
it just for one arch/package but its significant work and really painful.

A simple soname/soversion transition across all archs is much preferred.

> 	Jakub
Alastair

-- 
Alastair McKinstry, <alastair@sceal.ie>, <mckinstry@debian.org>, https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jonathan Wakely]

On Mon, 4 Oct 2021, 15:14 Jakub Jelinek via Gcc, <gcc@gcc.gnu.org> wrote:

> On Mon, Oct 04, 2021 at 12:07:54PM +0200, Jakub Jelinek via Gcc wrote:
> > Or the last option would be to try to make libgfortran.so.5 ABI
> compatible
> > with both choices on powerpc64le-linux.  From quick skimming of
> libgfortran,
> > we have lots of generated functions, which use HAVE_GFC_REAL_16 and
> > GFC_REAL_16 etc. macros.  So, we could perhaps arrange for the compiler
> > to use r16i or r17 instead of r16 in the names when real(kind=16) is the
> > IEEE quad on powerpc64le and keep using r16 for the IBM double double.
> > For the *.F90 generated files, one could achieve it by making sure
> > the *r16* files are compiled with -mabi=ibmlongdouble, for
> > *r16i* or *r17* with -mabi=ieeelongdouble and otherwise use kind=16 in
> > those, for *.c generated files the *GFC_* macros could just ensure that
> > it doesn't use long double but __ibm128 or __float128 depending on which
> one
> > is needed.
> > But then I see e.g. the io routines to just pass in kind and so
> > switch (kind) // or len
> >   {
> >   case ...:
> >     *(GFC_REAL_*) = ...;
> >   }
> > etc.  Could we just pretend in the compiler to libgfortran ABI that
> > powerpc64le-linux real(kind=16) is kind 17 and make sure that if anything
> > would actually think it is 17 bytes it uses 16 instead (though, kind=10
> > on x86-64 or i686 also isn't 10 bytes but 16 or 12, right?).
> >
> > Your thoughts on this?
>
> 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.
> libgfortran would then on powerpc64le-linux use -mabi=ieeelongdouble to
> make
> sure that regardless of the long double choice for C/C++ (whether default
> configure time selection or explicit -mabi=*) GFC_REAL_16 is the __float128
> long double.
> One problem with that is that I think IEEE quad long double support relies
> on glibc 2.32 or later, so not sure what exactly would be done if gcc is
> built against older glibc when it needs to call libm routines.  Perhaps
> convert to __ibm128, call the __ibm128 sinl etc. and convert back (big loss
> of precision and range, but at least something).
>
> What does libstdc++ do there?


All the new ieee128 support in libstdc++ is dependent on being built
against a new glibc. If you don't have a new glibc, you wish don't get any
C++ library support for ieee128. The SONAME doesn't change, but there are
additional symbols versions (and symbols) present in libstdc++.so.6 if
built against a new glibc.


>
>

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Michael Meissner]

On Mon, Oct 04, 2021 at 12:07:54PM +0200, Jakub Jelinek wrote:
> etc.  Could we just pretend in the compiler to libgfortran ABI that
> powerpc64le-linux real(kind=16) is kind 17 and make sure that if anything
> would actually think it is 17 bytes it uses 16 instead (though, kind=10
> on x86-64 or i686 also isn't 10 bytes but 16 or 12, right?).
> 
> Your thoughts on this?

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

Note the PowerPC has a third configure option for long double with the
configure option --without-long-double-128.  This option makes long double on
C/C++ be 64-bits instead of 128-bits.

In terms of enabling IEEE outside of PowerPC 64 LE Linux systems there are two
roadblocks:

1) The default configuration of BE systems is still Power4.  You need at least
Altivec registers to be able to pass and return IEEE 128-bit values.  However,
I am skeptical that configuring for a power6 could produce workable code, so
power7 is the theoretical minimum that could be used.  I limited it to power8
because the code needed direct moves and other ISA 3.0 support.  PowerPC 64-bit
LE has a minimum base level of power8, so it isn't an issue on that system.

2) The big stumbling block was that GLIBC only has IEEE 128-bit support for the
LE systems.  If there is BE glibc support, we could certainly add support for
enabling IEEE 128-bit in BE systems if the compiler was configured for power8
or higher.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Thomas Koenig]

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

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

Sounds like a reasonable minimum of user pain to me.

The rest I'll leave to the experts in all things ABI and POWER :-)

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek]

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

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Michael Meissner]

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

This is probably the right thing to do.  Note, it will effectively mean that
any fortran users on BE systems will no longer be able to use KIND=16.

It will also be a compatibility issue if users have code compiled on a LE
system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek]

On Thu, Oct 07, 2021 at 11:24:35AM -0400, Michael Meissner wrote:
> 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
> 
> This is probably the right thing to do.  Note, it will effectively mean that
> any fortran users on BE systems will no longer be able to use KIND=16.

Changing it on powerpc64le-linux doesn't imply we also have to change it
for powerpc64-linux, or perhaps can change it later than in GCC 12.

> It will also be a compatibility issue if users have code compiled on a LE
> system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.

libgfortran ABI changed multiple times in the past already, e.g. the
so.1 -> so.2 transition in 4.2
so.2 -> so.3 transition in 4.3
so.3 -> so.4 transition in 7
so.4 -> so.5 transition in 8
and users have coped.

	Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Thomas Koenig]

On 07.10.21 17:33, Jakub Jelinek wrote:
>> It will also be a compatibility issue if users have code compiled on a LE
>> system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.
> libgfortran ABI changed multiple times in the past already, e.g. the
> so.1 -> so.2 transition in 4.2
> so.2 -> so.3 transition in 4.3
> so.3 -> so.4 transition in 7
> so.4 -> so.5 transition in 8
> and users have coped.

Yes, and it has always been a hassle for users, and we've been
criticized for it.

This is currently a change which brings users on non-POWER-systems
(the vast majority) all pain and no gain.  If this cannot be
avoided, I would at least try to fit in as much of other improvements
as there are possible.

There's a PR for it somewhere, but I can think of three areas, none
of the small, and all require an ABI change:

a) Get PDTs right (Paul?)
b) Make file descriptors conform to the C interop version
c) Remove the run-time parsing of I/O arguments and
    replace them with a bit field.

What I mean by the last one is that

   WRITE (unit,'(A)',ADVANCE="NO")

we currently parse the "NO" at runtime, for every statement
execution.  What we could be doing instead is to have

dt_parm.0.advance = __gfortran_evaluate_yesno ("NO")

where the latter function can be simplified at compile-time.

We should strive to break the ABI as few times as possible.

Best regards

	Thomas

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Iain Sandoe]

> On 8 Oct 2021, at 07:35, Thomas Koenig via Fortran <fortran@gcc.gnu.org> wrote:
> 
> 
> On 07.10.21 17:33, Jakub Jelinek wrote:
>>> It will also be a compatibility issue if users have code compiled on a LE
>>> system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.
>> libgfortran ABI changed multiple times in the past already, e.g. the
>> so.1 -> so.2 transition in 4.2
>> so.2 -> so.3 transition in 4.3
>> so.3 -> so.4 transition in 7
>> so.4 -> so.5 transition in 8
>> and users have coped.
> 
> Yes, and it has always been a hassle for users, and we've been
> criticized for it.
> 
> This is currently a change which brings users on non-POWER-systems
> (the vast majority) all pain and no gain.  If this cannot be
> avoided, I would at least try to fit in as much of other improvements
> as there are possible.

If one wanted to prioritize library SO name stability - then, perhaps, the
approach Jonathan mentioned has been used for libstdc++ (add new
symbols for ieee128 with a different mangling to the existing r/c_16 ..)
would be preferable (the FE then has to choose the relevant symbol/
mangling depending on target).

.. perhaps I missed where that idea was already ruled out (in which case
sorry for the noise).
Iain
> 
> There's a PR for it somewhere, but I can think of three areas, none
> of the small, and all require an ABI change:
> 
> a) Get PDTs right (Paul?)
> b) Make file descriptors conform to the C interop version
> c) Remove the run-time parsing of I/O arguments and
>   replace them with a bit field.
> 
> What I mean by the last one is that
> 
>  WRITE (unit,'(A)',ADVANCE="NO")
> 
> we currently parse the "NO" at runtime, for every statement
> execution.  What we could be doing instead is to have
> 
> dt_parm.0.advance = __gfortran_evaluate_yesno ("NO")
> 
> where the latter function can be simplified at compile-time.
> 
> We should strive to break the ABI as few times as possible.
> 
> Best regards
> 
> 	Thomas

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Thomas Koenig]

Hi Iain,

> If one wanted to prioritize library SO name stability - then, perhaps, the
> approach Jonathan mentioned has been used for libstdc++ (add new
> symbols for ieee128 with a different mangling to the existing r/c_16 ..)
> would be preferable (the FE then has to choose the relevant symbol/
> mangling depending on target).

That's not all that would have to be changed.  Consider

   write (*,*) 1.0_16
end program

which is translated (using -fdump-tree-original) to


     _gfortran_st_write (&dt_parm.0);
     {
       static real(kind=16) C.3873 = 1.0e+0;

       _gfortran_transfer_real128_write (&dt_parm.0, &C.3873, 16);
     }
     _gfortran_st_write_done (&dt_parm.0);

so we actually pass a separate kind number as well (why, I'm not sure).
We would have to go through libgfortran with a fine comb to find all
the occurrences.  Probably some m4 hackery in iparm.m4 and ifunction.m4.
So, doable from the library side, if some work.

Things get interesting for user code, calling a routine compiled
for double double with newer IEEE QP will result in breakage.
We cannot use the KIND number to differentiate, because we must
assume that people have used KIND=16 and selected_real_kind(30)
interchangably, and we certainly do not want to nail people to
the old double double precision on hardware for which IEEE QP
is available.  So, KIND=15 for IEEE QP is out.

It's not an easy problem, unfortunately.

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Iain Sandoe]

Hi Thomas,

recognising that this is complex - the intent here is to see if there are ways
to partition the problem (where the pain falls does depend on the choices
made).

perhaps:

 *A  library (interface, name)
 *B  compiler internals
 *C  user-facing changes

> On 8 Oct 2021, at 17:26, Thomas Koenig <tkoenig@netcologne.de> wrote:
> 

>> If one wanted to prioritize library SO name stability - then, perhaps, the
>> approach Jonathan mentioned has been used for libstdc++ (add new
>> symbols for ieee128 with a different mangling to the existing r/c_16 ..)
>> would be preferable (the FE then has to choose the relevant symbol/
>> mangling depending on target).

(A) the points here ^^ are:

1/ the SO name could be left as it is
2/ a target that defaulted to QP routines would still (perhaps under
   some command line flag be able to use the older implementation).

I think both of those could be very helpful to end-users…

> That's not all that would have to be changed.


>  Consider
> 
>  write (*,*) 1.0_16
> end program
> 
> which is translated (using -fdump-tree-original) to
> 
> 
>    _gfortran_st_write (&dt_parm.0);
>    {
>      static real(kind=16) C.3873 = 1.0e+0;
> 
>      _gfortran_transfer_real128_write (&dt_parm.0, &C.3873, 16);
>    }
>    _gfortran_st_write_done (&dt_parm.0);
> 
> so we actually pass a separate kind number as well (why, I'm not sure).
> We would have to go through libgfortran with a fine comb to find all
> the occurrences.  Probably some m4 hackery in iparm.m4 and ifunction.m4.
> So, doable from the library side, if some work.

(B) This is the second area of interest, the fact that changes in the compiler internals
would be needed - and those take the time of the volunteers to implement (believe
me, I am painfully aware of how that pressure falls).

> Things get interesting for user code, calling a routine compiled
> for double double with newer IEEE QP will result in breakage.

That would not happen with the proposal above, since the library would
have different entry points for the two formats.

> We cannot use the KIND number to differentiate, because we must
> assume that people have used KIND=16 and selected_real_kind(30)
> interchangably, and we certainly do not want to nail people to
> the old double double precision on hardware for which IEEE QP
> is available.  

you don’t *have* to use the KIND number to differentiate to the library or the compiler
(although some alternate, more flexible, token would have to be invented).

(C) It’s the mapping between that internal token and the user’s view of the world that
needs to be defined in terms of what the combination of platform and command line
flags implies to the treatment of KIND=NN and selected_real_kind().

> So, KIND=15 for IEEE QP is out.

(C) I must confess this kind of change is where things seem very tricky to me.

changing how the language represents things seems to be something
that would benefit from agreement between compiler vendors

> It's not an easy problem, unfortunately.

no. it is not.
Iain

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Thomas Koenig]

Hi Iain,

>> Things get interesting for user code, calling a routine compiled
>> for double double with newer IEEE QP will result in breakage.
> That would not happen with the proposal above, since the library would
> have different entry points for the two formats.

I meant the case where the user writes, with an old, KIND=16 is double
double compiler,

   subroutine foo(a)
     real(kind=16) :: a
     a = a + 1._16
   end subroutine foo

and puts it in a library or an old object file, and in new code with an
IEEE QP compiler calls that with

   real(kind=16) :: a
   a = 2._16
   call foo(a)
   print *,a

this will result in silent generation of garbage values, since Fortran
does not mangle the function name based on it types. For both cases, the
subroutine will be called foo_  (or MOD..._foo).

There is no choice - we need to make object code compiled by the user
incompatible between the old and the new format on the systems where
we make the switch.

This is starting to look like a can of worms from Pandora's box,
if you pardon my mixed metaphors.

Best regards

	Thomas

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Iain Sandoe]

> On 8 Oct 2021, at 23:55, Thomas Koenig via Gcc <gcc@gcc.gnu.org> wrote:
> 
> 
> Hi Iain,
> 
>>> Things get interesting for user code, calling a routine compiled
>>> for double double with newer IEEE QP will result in breakage.
>> That would not happen with the proposal above, since the library would
>> have different entry points for the two formats.
> 
> I meant the case where the user writes, with an old, KIND=16 is double
> double compiler,
> 
>  subroutine foo(a)
>    real(kind=16) :: a
>    a = a + 1._16
>  end subroutine foo
> 
> and puts it in a library or an old object file, and in new code with an
> IEEE QP compiler calls that with
> 
>  real(kind=16) :: a
>  a = 2._16
>  call foo(a)
>  print *,a
> 
> this will result in silent generation of garbage values, since Fortran
> does not mangle the function name based on it types. For both cases, the
> subroutine will be called foo_  (or MOD..._foo).

hmm, well I thought about that case, but  … isn’t this “pilot error”?

if one compiles different parts of a project with incompatible command line options…

… or, say, compile with -mavx512 and then try to run code on hardware without
such a vector unit?

Getting wrong answers silently can likely be done with other command line
option mismatches.

Iain

> There is no choice - we need to make object code compiled by the user
> incompatible between the old and the new format on the systems where
> we make the switch.
> 
> This is starting to look like a can of worms from Pandora's box,
> if you pardon my mixed metaphors.

> 
> Best regards
> 
> 	Thomas

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Thomas Koenig]

On 09.10.21 01:18, Iain Sandoe wrote:
>> I meant the case where the user writes, with an old, KIND=16 is double
>> double compiler,
>>
>>   subroutine foo(a)
>>     real(kind=16) :: a
>>     a = a + 1._16
>>   end subroutine foo
>>
>> and puts it in a library or an old object file, and in new code with an
>> IEEE QP compiler calls that with
>>
>>   real(kind=16) :: a
>>   a = 2._16
>>   call foo(a)
>>   print *,a
>>
>> this will result in silent generation of garbage values, since Fortran
>> does not mangle the function name based on it types. For both cases, the
>> subroutine will be called foo_  (or MOD..._foo).
> hmm, well I thought about that case, but  … isn’t this “pilot error”?
> 
> if one compiles different parts of a project with incompatible command line options…
> 
> … or, say, compile with -mavx512 and then try to run code on hardware without
> such a vector unit?
> 
> Getting wrong answers silently can likely be done with other command line
> option mismatches.

Again, it depends.

What I was thinking about what a scenario where we do not change the
SONAME on POWER and rely on name mangling to get to the correct version
of a libgfortran library function. That could work, but it would not
work for user procedures.

I have thought of mangling the name of all user Fortran procedures
which contain a reference to an IEEE QP in their argument list, like
_foo%QP, but that would fall down for C interop.  So, no luck there.

So, a new SONAME at least on POWER is mandatory, I think.

The question is still if we can avoid a new SONAME for >99% of our users
for no gain at all for them.  Is there a possibility of aliasing the
SONAME somehow (grasping at straws here)?

Best regards

	Thomas

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Iain Sandoe]

> On 9 Oct 2021, at 10:11, Thomas Koenig <tkoenig@netcologne.de> wrote:
> 
> 
> On 09.10.21 01:18, Iain Sandoe wrote:
>>> I meant the case where the user writes, with an old, KIND=16 is double
>>> double compiler,
>>> 
>>>  subroutine foo(a)
>>>    real(kind=16) :: a
>>>    a = a + 1._16
>>>  end subroutine foo
>>> 
>>> and puts it in a library or an old object file, and in new code with an
>>> IEEE QP compiler calls that with
>>> 
>>>  real(kind=16) :: a
>>>  a = 2._16
>>>  call foo(a)
>>>  print *,a
>>> 
>>> this will result in silent generation of garbage values, since Fortran
>>> does not mangle the function name based on it types. For both cases, the
>>> subroutine will be called foo_  (or MOD..._foo).
>> hmm, well I thought about that case, but  … isn’t this “pilot error”?
>> if one compiles different parts of a project with incompatible command line options…
>> … or, say, compile with -mavx512 and then try to run code on hardware without
>> such a vector unit?
>> Getting wrong answers silently can likely be done with other command line
>> option mismatches.
> 
> Again, it depends.
> 
> What I was thinking about what a scenario where we do not change the
> SONAME on POWER and rely on name mangling to get to the correct version
> of a libgfortran library function. That could work, but it would not
> work for user procedures.

What I’m missing is why it has to.

IF  the user wants to use old (or not-owned) code compiled for double-double, then
she must select a command-line option to use that on Power(New).

Else

The user recompiles all the code in her project to use the new shiny QP.

I doubt there’s a way for this to proceed in a way that a user of Power (New) can
avoid having to think it through - a new library SO name won’t help them with the
interop with thier own (or not owned) code.

> I have thought of mangling the name of all user Fortran procedures
> which contain a reference to an IEEE QP in their argument list, like
> _foo%QP, but that would fall down for C interop.  So, no luck there.

agreed, I did the same thought exercise. 


> So, a new SONAME at least on POWER is mandatory, I think.
> 
> The question is still if we can avoid a new SONAME for >99% of our users
> for no gain at all for them.  Is there a possibility of aliasing the
> SONAME somehow (grasping at straws here)?
> 
> Best regards
> 
> 	Thomas

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek]

On Sat, Oct 09, 2021 at 11:11:51AM +0200, Thomas Koenig wrote:
> The question is still if we can avoid a new SONAME for >99% of our users
> for no gain at all for them.  Is there a possibility of aliasing the
> SONAME somehow (grasping at straws here)?

I'd hope Debian can just
ln -sf libgfortran.so.5 libgfortran.so.6
as their libgfortran6 package for non-ppc64le and make it depend on
libgfortran5 if they really want to do something and GCC itself doesn't need
to care, except for libgfortran/Makefile.in which would need to adjust
`grep -v '^\#' $(srcdir)/libtool-version`
to conditionally (for ppc64le only) sed 's/^5:/6:/' in it).

	Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Andreas Schwab]

On Okt 09 2021, Thomas Koenig via Fortran wrote:

> There is no choice - we need to make object code compiled by the user
> incompatible between the old and the new format on the systems where
> we make the switch.

If you link, but not recompile, object files compiled against different
versions of glibc, you are in for surprises, too.  This isn't something
new.  There is no guarantee of API stability.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Florian Weimer]

* Andreas Schwab:

> On Okt 09 2021, Thomas Koenig via Fortran wrote:
>
>> There is no choice - we need to make object code compiled by the user
>> incompatible between the old and the new format on the systems where
>> we make the switch.
>
> If you link, but not recompile, object files compiled against different
> versions of glibc, you are in for surprises, too.  This isn't something
> new.  There is no guarantee of API stability.

This is of course true, but we nevertheless try to accommodate
existing static linking patterns with glibc if possible.  Maybe those
are more common with Fortran?  Then more compatibility for static
linking could be pretty much required there.  (I don't know enough
about Fortran to judge that.)

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Bill Schmidt]

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.

===

Longer term, we have the question of supporting more Power targets.  AIX will continue to
use only double-double.  It is agreed that it would be useful for 32- and 64-bit BE Linux
to support IEEE QP as well, on some future timeline.  The first step towards this is to
develop and document ABI for IEEE QP on those targets.  The simplest approach that everyone
seemed to like is for these ABIs to require AltiVec support in order for IEEE QP to be
supported.  This allows parameters and return values to always be passed in vector registers,
whether implemented with hardware instructions or a soft-float library.  libquadmath can
be built for these targets.

[Sidebar: The ELFv1 document needs a new home, as the last version was published by the
now-defunct POWER.org.  But we can deal with that.]

Beyond ABI and compiler support, glibc would also need to support IEEE QP for these other
targets.  Currently we only have support for powerpc64le.

===

Is this a fair summary of the results of the discussion?

Thanks again!
Bill

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek]

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

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Thomas Koenig]

On 15.10.21 16:20, Jakub Jelinek wrote:

[...]

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

There is one potential problem: selected_real_kind.

The standard says about that...

# If more than one kind type parameter value meets the criteria, the
# value returned is the one with the smallest decimal precision, unless
# there are several such values, in which case the smallest of these
# kind values is returned

So, selected_real_kind(25) would yield double double, and we would
have to violate the standard there if we wanted people to have
IEEE QP in that case.

Best regards

	Thomas

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Jakub Jelinek]

On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote:
> > 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.
> 
> There is one potential problem: selected_real_kind.
> 
> The standard says about that...
> 
> # If more than one kind type parameter value meets the criteria, the
> # value returned is the one with the smallest decimal precision, unless
> # there are several such values, in which case the smallest of these
> # kind values is returned
> 
> So, selected_real_kind(25) would yield double double, and we would
> have to violate the standard there if we wanted people to have
> IEEE QP in that case.

That would be true if some kind exist for double double, whether
it is kind == 15 or kind == 17, no?
Because precision (0.0_double_double_kind) < precision (0.0_ieee_quad_kind)
so the "smallest of the kind values" doesn't trigger.

	Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Thomas Koenig]

On 15.10.21 20:11, Jakub Jelinek wrote:
> On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote:
>>> 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.
>>
>> There is one potential problem: selected_real_kind.
>>
>> The standard says about that...
>>
>> # If more than one kind type parameter value meets the criteria, the
>> # value returned is the one with the smallest decimal precision, unless
>> # there are several such values, in which case the smallest of these
>> # kind values is returned
>>
>> So, selected_real_kind(25) would yield double double, and we would
>> have to violate the standard there if we wanted people to have
>> IEEE QP in that case.
> 
> That would be true if some kind exist for double double, whether
> it is kind == 15 or kind == 17, no?

Correct.  The authors probably did not think of this particular
case when they wrote the standard.

We can ask the J3 standards committee to change the wording.  I think
I will just do that, to see what they have to say.

Best regards

	Thomas

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

On Fri, Oct 15, 2021 at 04:20:49PM +0200, Jakub Jelinek wrote:
> 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.

Yes.

We want KIND=16 to mean the IEEE QP format whenever we can, right?  And
another 16-byte format would more logically be kind=17 then, considering
we want to have two 2-byte kinds at least, one of them IEEE as well.

Other practical considerations might well supersede elegance of course.


Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Segher Boessenkool]

Thank you for writing this out Bill!

On Fri, Oct 15, 2021 at 08:50:08AM -0500, Bill Schmidt wrote:
> Longer term, we have the question of supporting more Power targets.  AIX will continue to
> use only double-double.

Yes.  So it will be virtually no cost to continue supporting
double-double on all targets (implementation cost that is -- maintenance
cost will actually be negative for keeping it for a while, old data
sticks around for a very long time.)

> It is agreed that it would be useful for 32- and 64-bit BE Linux
> to support IEEE QP as well, on some future timeline.  The first step towards this is to
> develop and document ABI for IEEE QP on those targets.  The simplest approach that everyone
> seemed to like is for these ABIs to require AltiVec support in order for IEEE QP to be
> supported.  This allows parameters and return values to always be passed in vector registers,
> whether implemented with hardware instructions or a soft-float library.  libquadmath can
> be built for these targets.

This is a great choice for the ABIs that have AltiVec enabled, yes.  It
requires almost no modification to the parameter passing for them
(ignoring the obvious fact that it changes where long double is passed,
if long double now is IEEE QP; similarly, KIND=16), it can be just the
same as anything else passed in VRs.

At a later date we can consider having QP for ABIs without AltiVec as
well, if there is any interest in that.  Since there exists no such
thing yet, having QP passed in VRs will be easy to do everywhere :-)


Segher

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Fri, 15 Oct 2021, Bill Schmidt via Gcc wrote:

> Beyond ABI and compiler support, glibc would also need to support IEEE 
> QP for these other targets.  Currently we only have support for 
> powerpc64le.

And that would involve new syntax in glibc Versions files, as discussed in 
<https://gcc.gnu.org/pipermail/gcc/2021-October/237510.html>, to give the 
binary128 versions of certain functions (functions added after the initial 
_Float128 support was added to glibc but before it gets added for these 
other ABIs) the right symbol version.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Michael Meissner]

I've played with some patches to PowerPC to set the defaults for fortran.  But
without doing a full rebuild like you would do with a new distribution, I think
it will be problematical, unless you build everything with the default long
double set to IEEE 128-bit.

First off all, libquadmath is currently built on Linux 64-bit systems.  I never
removed building libquadmath once we got the official glibc 2.34 support

So to go in more detail of what I've tried.

I added an undocumented switch -mfortran that says set the defaults for
Fortran.  This switch would be used to build libgfortran, and also set with
TARGET_F951_OPTIONS for all Fortran invocations.

I tried to switch to float128_type_node instead of long_double_type_node.  I
ran into problems with gimplify in that it could not do a conversion from
_Float128 to float.  I suspect I didn't actually use the right type.

I then went to patches where -mfortran silently switches the long double type
to IEEE 128-bit.  There you get into various compatibility issues where the
linker complains that you are calling between the different long double types.

For instance because we are still building libquadmath, libquadmath is marked
as having long double being IBM 128-bit, but it is called from Fortran modules
that have long double being IEEE 128-bit.  I then did a build supressing
building libquadmath since I was using LE with glibc 2.34, and I got much
further.  This time instead of a lot of failures, I got 29 failures, due to
libgfortran still being marked as IBM long double and the fortran modules are
marked as IEEE long double.

Right now, the only way to avoid these things is to build the entire toolchain
defaulting to IEEE 128-bit.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)

[Michael Meissner]

Here are the patches I worked on today.  It does seem to fix KIND=16 to use
Float128, but by not considering long double for KIND processing, it breaks the
tests that want to do ISO C binding to long double.

Feel free to completely ignore the patches and go off in a different
direction.  But I thought it would be useful to share what I've done.

> From 443773ac040383311384577b48ecc0bd957ff328 Mon Sep 17 00:00:00 2001
> From: Michael Meissner <meissner@linux.ibm.com>
> Date: Thu, 28 Oct 2021 23:23:53 -0400
> Subject: [PATCH] Initial patch for PowerPC Fortran KIND=16

This is a work in progress patch.  It attempts to make Fortran KIND=16 to
always mean Float128 on PowerPC VSX systems.  Unfortunately, in changing
KIND=16 to Float128, it breaks all of the ISO C bindings for long double
support in Fortran.

gcc/

2021-10-28  Michael Meissner  <meissner@the-meissners.org>

	* config/rs6000/rs6000.h (FORTRAN_USE_FLOAT128): New macro.
	(FORTRAN_USE_LONG_DOUBLE): New macro.
	* tree.h (complex_float128_type_node): Define.
	* doc/tm.texi.in (FORTRAN_USE_FLOAT128): Add documentation.
	(FORTRAN_USE_LONG_DOUBLE): Likewise.
	* doc/tm.texi: Regenerate.

gcc/fortran/

2021-10-28  Michael Meissner  <meissner@the-meissners.org>

	* f95-lang.c (gfc_init_builtin_functions): Flesh out more Float128
	support.
	* gfortran.h (FORTRAN_USE_LONG_DOUBLE): Provide default
	definition.
	(FORTRAN_USE_FLOAT128): Likewise.
	* trans-types.c (gfc_init_kinds): Add support for
	FORTRAN_USE_LONG_DOUBLE and FORTRAN_USE_FLOAT128.
	(gfc_build_real_type): Likewise.
	(gfc_build_complex_type): Add support for Float128 complex.
---
 gcc/config/rs6000/rs6000.h | 10 ++++++++++
 gcc/doc/tm.texi            | 13 +++++++++++++
 gcc/doc/tm.texi.in         | 13 +++++++++++++
 gcc/fortran/f95-lang.c     | 28 ++++++++++++++++++++++++++++
 gcc/fortran/gfortran.h     | 13 +++++++++++++
 gcc/fortran/trans-types.c  | 24 +++++++++++++++++-------
 gcc/tree.h                 |  2 ++
 7 files changed, 96 insertions(+), 7 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 3eba1c072cf..4e016e548db 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -2691,3 +2691,13 @@ while (0)
        rs6000_asm_output_opcode (STREAM);				\
     }									\
   while (0)
+
+/* Whether Fortran should use long double or __float128 for KIND=16.  If we
+   support IEEE 128-bit and long double is not IEEE 128-bit, then use the
+   _Float128 type for KIND=16.  Otherwise use long double.  */
+#undef FORTRAN_USE_FLOAT128
+#define FORTRAN_USE_FLOAT128	(TARGET_FLOAT128_TYPE && !TARGET_IEEEQUAD)
+
+#undef FORTRAN_USE_LONG_DOUBLE
+#define FORTRAN_USE_LONG_DOUBLE	(!FORTRAN_USE_FLOAT128)
+
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 902402d7503..13ecca2605c 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -12612,3 +12612,16 @@ counters are incremented using atomic operations.  Targets not supporting
 64-bit atomic operations may override the default value and request a 32-bit
 type.
 @end deftypefn
+
+@defmac FORTRAN_USE_LONG_DOUBLE
+Define this macro to return true if Fortran should enable @code{long
+double} support for @code{KIND} processing.  If you do not define this
+macro, Fortran always uses the @code{long double} type.
+@end defmac
+
+@defmac FORTRAN_USE_LONG_DOUBLE
+Define this macro to return true if Fortran should enable
+@code{_Float128} support for @code{KIND} processing.  If you do not
+define this macro, Fortran will enable @code{_Float128} support if the
+quadmath library is built, and the mode @code{TFmode} is enabled.
+@end defmac
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 86352dc9bd2..012ef1ecc98 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -8187,3 +8187,16 @@ maintainer is familiar with.
 @hook TARGET_MEMTAG_UNTAGGED_POINTER
 
 @hook TARGET_GCOV_TYPE_SIZE
+
+@defmac FORTRAN_USE_LONG_DOUBLE
+Define this macro to return true if Fortran should enable @code{long
+double} support for @code{KIND} processing.  If you do not define this
+macro, Fortran always uses the @code{long double} type.
+@end defmac
+
+@defmac FORTRAN_USE_LONG_DOUBLE
+Define this macro to return true if Fortran should enable
+@code{_Float128} support for @code{KIND} processing.  If you do not
+define this macro, Fortran will enable @code{_Float128} support if the
+quadmath library is built, and the mode @code{TFmode} is enabled.
+@end defmac
diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
index 58dcaf01d75..b8117dc72b4 100644
--- a/gcc/fortran/f95-lang.c
+++ b/gcc/fortran/f95-lang.c
@@ -674,9 +674,11 @@ gfc_init_builtin_functions (void)
   tree mfunc_float[6];
   tree mfunc_double[6];
   tree mfunc_longdouble[6];
+  tree mfunc_float128[6];
   tree mfunc_cfloat[6];
   tree mfunc_cdouble[6];
   tree mfunc_clongdouble[6];
+  tree mfunc_cfloat128[6];
   tree func_cfloat_float, func_float_cfloat;
   tree func_cdouble_double, func_double_cdouble;
   tree func_clongdouble_longdouble, func_longdouble_clongdouble;
@@ -691,9 +693,11 @@ gfc_init_builtin_functions (void)
   build_builtin_fntypes (mfunc_float, float_type_node);
   build_builtin_fntypes (mfunc_double, double_type_node);
   build_builtin_fntypes (mfunc_longdouble, long_double_type_node);
+  build_builtin_fntypes (mfunc_float128, float128_type_node);
   build_builtin_fntypes (mfunc_cfloat, complex_float_type_node);
   build_builtin_fntypes (mfunc_cdouble, complex_double_type_node);
   build_builtin_fntypes (mfunc_clongdouble, complex_long_double_type_node);
+  build_builtin_fntypes (mfunc_cfloat128, complex_float128_type_node);
 
   func_cfloat_float = build_function_type_list (float_type_node,
                                                 complex_float_type_node,
@@ -736,6 +740,8 @@ gfc_init_builtin_functions (void)
 
   gfc_define_builtin ("__builtin_roundl", mfunc_longdouble[0], 
 		      BUILT_IN_ROUNDL, "roundl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  gfc_define_builtin ("__builtin_roundf128", mfunc_float128[0], 
+		      BUILT_IN_ROUNDF128, "roundf128", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_round", mfunc_double[0], 
 		      BUILT_IN_ROUND, "round", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_roundf", mfunc_float[0], 
@@ -743,6 +749,8 @@ gfc_init_builtin_functions (void)
 
   gfc_define_builtin ("__builtin_truncl", mfunc_longdouble[0],
 		      BUILT_IN_TRUNCL, "truncl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  gfc_define_builtin ("__builtin_truncf128", mfunc_float128[0],
+		      BUILT_IN_TRUNCF128, "truncl", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_trunc", mfunc_double[0],
 		      BUILT_IN_TRUNC, "trunc", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_truncf", mfunc_float[0],
@@ -750,6 +758,7 @@ gfc_init_builtin_functions (void)
 
   gfc_define_builtin ("__builtin_cabsl", func_clongdouble_longdouble, 
 		      BUILT_IN_CABSL, "cabsl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_cabsf128.  */
   gfc_define_builtin ("__builtin_cabs", func_cdouble_double, 
 		      BUILT_IN_CABS, "cabs", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_cabsf", func_cfloat_float, 
@@ -758,6 +767,9 @@ gfc_init_builtin_functions (void)
   gfc_define_builtin ("__builtin_copysignl", mfunc_longdouble[1], 
 		      BUILT_IN_COPYSIGNL, "copysignl",
 		      ATTR_CONST_NOTHROW_LEAF_LIST);
+  gfc_define_builtin ("__builtin_copysignf128", mfunc_longdouble[1], 
+		      BUILT_IN_COPYSIGNF128, "copysignf128",
+		      ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_copysign", mfunc_double[1], 
 		      BUILT_IN_COPYSIGN, "copysign",
 		      ATTR_CONST_NOTHROW_LEAF_LIST);
@@ -768,6 +780,7 @@ gfc_init_builtin_functions (void)
   gfc_define_builtin ("__builtin_nextafterl", mfunc_longdouble[1], 
 		      BUILT_IN_NEXTAFTERL, "nextafterl",
 		      ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_nextafterf128.  */
   gfc_define_builtin ("__builtin_nextafter", mfunc_double[1], 
 		      BUILT_IN_NEXTAFTER, "nextafter",
 		      ATTR_CONST_NOTHROW_LEAF_LIST);
@@ -781,6 +794,8 @@ gfc_init_builtin_functions (void)
 
   gfc_define_builtin ("__builtin_rintl", mfunc_longdouble[0], 
 		      BUILT_IN_RINTL, "rintl", attr);
+  gfc_define_builtin ("__builtin_rintf128", mfunc_float128[0], 
+		      BUILT_IN_RINTF128, "rintf128", attr);
   gfc_define_builtin ("__builtin_rint", mfunc_double[0], 
 		      BUILT_IN_RINT, "rint", attr);
   gfc_define_builtin ("__builtin_rintf", mfunc_float[0], 
@@ -788,6 +803,7 @@ gfc_init_builtin_functions (void)
 
   gfc_define_builtin ("__builtin_remainderl", mfunc_longdouble[1], 
 		      BUILT_IN_REMAINDERL, "remainderl", attr);
+  /* no __builtin_remainderf128.  */
   gfc_define_builtin ("__builtin_remainder", mfunc_double[1], 
 		      BUILT_IN_REMAINDER, "remainder", attr);
   gfc_define_builtin ("__builtin_remainderf", mfunc_float[1], 
@@ -795,6 +811,7 @@ gfc_init_builtin_functions (void)
  
   gfc_define_builtin ("__builtin_logbl", mfunc_longdouble[0], 
 		      BUILT_IN_LOGBL, "logbl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_logbf128.  */
   gfc_define_builtin ("__builtin_logb", mfunc_double[0], 
 		      BUILT_IN_LOGB, "logb", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_logbf", mfunc_float[0], 
@@ -803,6 +820,7 @@ gfc_init_builtin_functions (void)
 
   gfc_define_builtin ("__builtin_frexpl", mfunc_longdouble[4], 
 		      BUILT_IN_FREXPL, "frexpl", ATTR_NOTHROW_LEAF_LIST);
+  /* no __builtin_frexpf128.  */
   gfc_define_builtin ("__builtin_frexp", mfunc_double[4], 
 		      BUILT_IN_FREXP, "frexp", ATTR_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_frexpf", mfunc_float[4], 
@@ -810,6 +828,8 @@ gfc_init_builtin_functions (void)
  
   gfc_define_builtin ("__builtin_fabsl", mfunc_longdouble[0], 
 		      BUILT_IN_FABSL, "fabsl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  gfc_define_builtin ("__builtin_fabsf128", mfunc_float128[0], 
+		      BUILT_IN_FABSF128, "fabsf128", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_fabs", mfunc_double[0], 
 		      BUILT_IN_FABS, "fabs", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_fabsf", mfunc_float[0], 
@@ -817,6 +837,7 @@ gfc_init_builtin_functions (void)
  
   gfc_define_builtin ("__builtin_scalbnl", mfunc_longdouble[2],
 		      BUILT_IN_SCALBNL, "scalbnl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_scalbnf128.  */
   gfc_define_builtin ("__builtin_scalbn", mfunc_double[2],
 		      BUILT_IN_SCALBN, "scalbn", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_scalbnf", mfunc_float[2],
@@ -824,6 +845,7 @@ gfc_init_builtin_functions (void)
  
   gfc_define_builtin ("__builtin_fmodl", mfunc_longdouble[1], 
 		      BUILT_IN_FMODL, "fmodl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_fmodf128.  */
   gfc_define_builtin ("__builtin_fmod", mfunc_double[1], 
 		      BUILT_IN_FMOD, "fmod", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_fmodf", mfunc_float[1], 
@@ -872,18 +894,21 @@ gfc_init_builtin_functions (void)
   /* These are used to implement the ** operator.  */
   gfc_define_builtin ("__builtin_powl", mfunc_longdouble[1], 
 		      BUILT_IN_POWL, "powl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_powf128.  */
   gfc_define_builtin ("__builtin_pow", mfunc_double[1], 
 		      BUILT_IN_POW, "pow", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_powf", mfunc_float[1], 
 		      BUILT_IN_POWF, "powf", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_cpowl", mfunc_clongdouble[1], 
 		      BUILT_IN_CPOWL, "cpowl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_cpowf128.  */
   gfc_define_builtin ("__builtin_cpow", mfunc_cdouble[1], 
 		      BUILT_IN_CPOW, "cpow", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_cpowf", mfunc_cfloat[1], 
 		      BUILT_IN_CPOWF, "cpowf", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_powil", mfunc_longdouble[2],
 		      BUILT_IN_POWIL, "powil", ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_powif128.  */
   gfc_define_builtin ("__builtin_powi", mfunc_double[2],
 		      BUILT_IN_POWI, "powi", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_powif", mfunc_float[2],
@@ -895,6 +920,7 @@ gfc_init_builtin_functions (void)
       gfc_define_builtin ("__builtin_cbrtl", mfunc_longdouble[0],
 			  BUILT_IN_CBRTL, "cbrtl",
 			  ATTR_CONST_NOTHROW_LEAF_LIST);
+      /* no __builtin_cbrtf128.  */
       gfc_define_builtin ("__builtin_cbrt", mfunc_double[0],
 			  BUILT_IN_CBRT, "cbrt",
 			  ATTR_CONST_NOTHROW_LEAF_LIST);
@@ -904,6 +930,7 @@ gfc_init_builtin_functions (void)
       gfc_define_builtin ("__builtin_cexpil", func_longdouble_clongdouble, 
 			  BUILT_IN_CEXPIL, "cexpil",
 			  ATTR_CONST_NOTHROW_LEAF_LIST);
+      /* no __builtin_cexpif128.  */
       gfc_define_builtin ("__builtin_cexpi", func_double_cdouble,
 			  BUILT_IN_CEXPI, "cexpi",
 			  ATTR_CONST_NOTHROW_LEAF_LIST);
@@ -917,6 +944,7 @@ gfc_init_builtin_functions (void)
       gfc_define_builtin ("__builtin_sincosl",
 			  func_longdouble_longdoublep_longdoublep,
 			  BUILT_IN_SINCOSL, "sincosl", ATTR_NOTHROW_LEAF_LIST);
+      /* no __builtin_sincosf128.  */
       gfc_define_builtin ("__builtin_sincos", func_double_doublep_doublep,
 			  BUILT_IN_SINCOS, "sincos", ATTR_NOTHROW_LEAF_LIST);
       gfc_define_builtin ("__builtin_sincosf", func_float_floatp_floatp,
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index c25d1cca3a8..15c940b0f31 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3791,4 +3791,17 @@ bool gfc_is_reallocatable_lhs (gfc_expr *);
 void finish_oacc_declare (gfc_namespace *, gfc_symbol *, bool);
 void gfc_adjust_builtins (void);
 
+/* Whether to enable long double and/or float128 processing.  */
+#ifndef FORTRAN_USE_LONG_DOUBLE
+#define FORTRAN_USE_LONG_DOUBLE		1
+#endif
+
+#ifndef FORTRAN_USE_FLOAT128
+#if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT)
+#define FORTRAN_USE_FLOAT128		1
+#else
+#define FORTRAN_USE_FLOAT128		0
+#endif
+#endif
+
 #endif /* GCC_GFORTRAN_H  */
diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index 1c78a906397..6803b832183 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -453,10 +453,10 @@ gfc_init_kinds (void)
 	continue;
       if (mode != TYPE_MODE (float_type_node)
 	    && (mode != TYPE_MODE (double_type_node))
-	    && (mode != TYPE_MODE (long_double_type_node))
-#if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT)
-	    && (mode != TFmode)
-#endif
+	    && (!FORTRAN_USE_LONG_DOUBLE
+		|| mode != TYPE_MODE (long_double_type_node))
+	    && (!FORTRAN_USE_FLOAT128
+		|| mode != TYPE_MODE (float128_type_node))
 	   )
 	continue;
 
@@ -854,9 +854,14 @@ gfc_build_real_type (gfc_real_info *info)
     info->c_float = 1;
   if (mode_precision == DOUBLE_TYPE_SIZE)
     info->c_double = 1;
-  if (mode_precision == LONG_DOUBLE_TYPE_SIZE)
+  if (FORTRAN_USE_LONG_DOUBLE && mode_precision == LONG_DOUBLE_TYPE_SIZE)
     info->c_long_double = 1;
-  if (mode_precision != LONG_DOUBLE_TYPE_SIZE && mode_precision == 128)
+
+  /* Don't check for just mode_precision == 128 for Float128.  On the PowerPC,
+     there are 3 different 128-bit floating point types (IEEE 128-bit, IBM
+     128-bit, and the default long double, which is either of the other types).
+     The precision is used to differentiate between the types.  */
+  if (FORTRAN_USE_FLOAT128 && IN_RANGE (mode_precision, 126, 128))
     {
       /* TODO: see PR101835.  */
       info->c_float128 = 1;
@@ -867,8 +872,11 @@ gfc_build_real_type (gfc_real_info *info)
     return float_type_node;
   if (TYPE_PRECISION (double_type_node) == mode_precision)
     return double_type_node;
-  if (TYPE_PRECISION (long_double_type_node) == mode_precision)
+  if (FORTRAN_USE_LONG_DOUBLE
+      && TYPE_PRECISION (long_double_type_node) == mode_precision)
     return long_double_type_node;
+  if (FORTRAN_USE_FLOAT128 && IN_RANGE (mode_precision, 126, 128))
+    return float128_type_node;
 
   new_type = make_node (REAL_TYPE);
   TYPE_PRECISION (new_type) = mode_precision;
@@ -889,6 +897,8 @@ gfc_build_complex_type (tree scalar_type)
     return complex_double_type_node;
   if (scalar_type == long_double_type_node)
     return complex_long_double_type_node;
+  if (scalar_type == float128_type_node)
+    return complex_float128_type_node;
 
   new_type = make_node (COMPLEX_TYPE);
   TREE_TYPE (new_type) = scalar_type;
diff --git a/gcc/tree.h b/gcc/tree.h
index 7542d97ce12..f3b47f81a09 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -4225,6 +4225,8 @@ tree_strip_any_location_wrapper (tree exp)
 #define complex_double_type_node	global_trees[TI_COMPLEX_DOUBLE_TYPE]
 #define complex_long_double_type_node	global_trees[TI_COMPLEX_LONG_DOUBLE_TYPE]
 
+#define complex_float128_type_node	global_trees[TI_COMPLEX_FLOAT128_TYPE]
+
 #define COMPLEX_FLOATN_NX_TYPE_NODE(IDX)	global_trees[TI_COMPLEX_FLOATN_NX_TYPE_FIRST + (IDX)]
 
 #define void_type_node			global_trees[TI_VOID_TYPE]
-- 
2.31.1



-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)

[Thomas Koenig]

Hi Michael,

I tried this out on the one POWER machine where I can get something
installed :-) It runs Ubuntu 20.04, but does not appear to have the
right glibc version; it has

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.1 LTS
Release:        20.04
Codename:       focal
$ ldd --version
ldd (Ubuntu GLIBC 2.31-0ubuntu9.1) 2.31

Configure was

./trunk/configure --prefix=$HOME --enable-languages=c,c++,fortran 
--with-advance-toolchain=at15.0 
--with-native-system-header-dir=/opt/at15.0/include 
--with-long-double-format=ieee

and the error message

msgfmt -o fr.mo ../../../../trunk/libstdc++-v3/po/fr.po
msgfmt: /lib/powerpc64le-linux-gnu/libm.so.6: version `GLIBC_2.32' not 
found (required by 
/home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6)
msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not 
found (required by 
/home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6)
msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not 
found (required by 
/home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6)
msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not 
found (required by 
/home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6)
msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not 
found (required by /home/ig25/trunk-bin/./gcc/libgcc_s.so.1)

and so on.

Since gcc135 is also too old, that exhausts my possibilities at testing.

Any hints on how best to proceed?

Best regards

	Thomas

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)

[Michael Meissner]

On Fri, Oct 29, 2021 at 09:07:38PM +0200, Thomas Koenig wrote:
> Hi Michael,
> 
> I tried this out on the one POWER machine where I can get something
> installed :-) It runs Ubuntu 20.04, but does not appear to have the
> right glibc version; it has
> 
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:    Ubuntu 20.04.1 LTS
> Release:        20.04
> Codename:       focal
> $ ldd --version
> ldd (Ubuntu GLIBC 2.31-0ubuntu9.1) 2.31
> 
> Configure was
> 
> ./trunk/configure --prefix=$HOME --enable-languages=c,c++,fortran
> --with-advance-toolchain=at15.0
> --with-native-system-header-dir=/opt/at15.0/include
> --with-long-double-format=ieee
> 
> and the error message
> 
> msgfmt -o fr.mo ../../../../trunk/libstdc++-v3/po/fr.po
> msgfmt: /lib/powerpc64le-linux-gnu/libm.so.6: version `GLIBC_2.32' not found
> (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6)
> msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not found
> (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6)
> msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
> (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6)
> msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found
> (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6)
> msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
> (required by /home/ig25/trunk-bin/./gcc/libgcc_s.so.1)
> 
> and so on.
> 
> Since gcc135 is also too old, that exhausts my possibilities at testing.
> 
> Any hints on how best to proceed?
> 
> Best regards

As I've delved into it, it looks glibc 2.34 is really only needed for switching
long double over to IEEE 128-bit, since it has all of the F128 functions that
would be needed.  That is because Fortran uses the 'q' names which are in
libquadmath (that should be built).

I built the original version with:

        --prefix=/home/meissner/fsf-install-ppc64le/fortran-orig \
        --enable-languages=c,c++,fortran \
        --disable-plugin \
        --enable-checking \
        --enable-stage1-checking \
        --enable-gnu-indirect-function \
        --disable-libgomp \
        --enable-decimal-float \
        --enable-secureplt \
        --enable-threads=posix \
        --enable-__cxa_atexit \
        --with-long-double-128 \
        --with-long-double-format=ibm \
        --with-cpu=power9 \
        --with-as=/opt/at12.0/bin/as \
        --with-ld=/opt/at12.0/bin/ld \
        --with-gnu-as=/opt/at12.0/bin/as \
        --with-gnu-ld=/opt/at12.0/bin/ld \
        --with-gmp=/home/meissner/tools-compiler/ppc64le \
        --with-mpfr=/home/meissner/tools-compiler/ppc64le \
        --with-mpc=/home/meissner/tools-compiler/ppc64le \
        --without-ppl \
        --without-cloog \
        --without-isl

I needed to build my own version of mpfs, mpc, and gmp.  I built them without
shared libraries, because I get messages like you get.

I have a new version of the patch that makes new target hooks to allow the
backend to specify KIND numbers for types.  I choose kind=16 to always be IEEE
128-bit, and kind=15 to be long double if long double is IBM (since I
discovered yesterday, Fortran needs to be able to deal with long double).  I'm
in the middle of the build an on internal IBM system, and I will start the
build on gcc135 shortly.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)

[Bill Schmidt]

Would starting from Advance Toolchain 15 with the most recent glibc make things easier for Thomas to test?

Thanks,
Bill

On 10/29/21 4:06 PM, Michael Meissner via Gcc wrote:
> On Fri, Oct 29, 2021 at 09:07:38PM +0200, Thomas Koenig wrote:
>> Hi Michael,
>>
>> I tried this out on the one POWER machine where I can get something
>> installed :-) It runs Ubuntu 20.04, but does not appear to have the
>> right glibc version; it has
>>
>> $ lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description:    Ubuntu 20.04.1 LTS
>> Release:        20.04
>> Codename:       focal
>> $ ldd --version
>> ldd (Ubuntu GLIBC 2.31-0ubuntu9.1) 2.31
>>
>> Configure was
>>
>> ./trunk/configure --prefix=$HOME --enable-languages=c,c++,fortran
>> --with-advance-toolchain=at15.0
>> --with-native-system-header-dir=/opt/at15.0/include
>> --with-long-double-format=ieee
>>
>> and the error message
>>
>> msgfmt -o fr.mo ../../../../trunk/libstdc++-v3/po/fr.po
>> msgfmt: /lib/powerpc64le-linux-gnu/libm.so.6: version `GLIBC_2.32' not found
>> (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6)
>> msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not found
>> (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6)
>> msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
>> (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6)
>> msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found
>> (required by /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6)
>> msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
>> (required by /home/ig25/trunk-bin/./gcc/libgcc_s.so.1)
>>
>> and so on.
>>
>> Since gcc135 is also too old, that exhausts my possibilities at testing.
>>
>> Any hints on how best to proceed?
>>
>> Best regards
> As I've delved into it, it looks glibc 2.34 is really only needed for switching
> long double over to IEEE 128-bit, since it has all of the F128 functions that
> would be needed.  That is because Fortran uses the 'q' names which are in
> libquadmath (that should be built).
>
> I built the original version with:
>
>         --prefix=/home/meissner/fsf-install-ppc64le/fortran-orig \
>         --enable-languages=c,c++,fortran \
>         --disable-plugin \
>         --enable-checking \
>         --enable-stage1-checking \
>         --enable-gnu-indirect-function \
>         --disable-libgomp \
>         --enable-decimal-float \
>         --enable-secureplt \
>         --enable-threads=posix \
>         --enable-__cxa_atexit \
>         --with-long-double-128 \
>         --with-long-double-format=ibm \
>         --with-cpu=power9 \
>         --with-as=/opt/at12.0/bin/as \
>         --with-ld=/opt/at12.0/bin/ld \
>         --with-gnu-as=/opt/at12.0/bin/as \
>         --with-gnu-ld=/opt/at12.0/bin/ld \
>         --with-gmp=/home/meissner/tools-compiler/ppc64le \
>         --with-mpfr=/home/meissner/tools-compiler/ppc64le \
>         --with-mpc=/home/meissner/tools-compiler/ppc64le \
>         --without-ppl \
>         --without-cloog \
>         --without-isl
>
> I needed to build my own version of mpfs, mpc, and gmp.  I built them without
> shared libraries, because I get messages like you get.
>
> I have a new version of the patch that makes new target hooks to allow the
> backend to specify KIND numbers for types.  I choose kind=16 to always be IEEE
> 128-bit, and kind=15 to be long double if long double is IBM (since I
> discovered yesterday, Fortran needs to be able to deal with long double).  I'm
> in the middle of the build an on internal IBM system, and I will start the
> build on gcc135 shortly.
>

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)

[Michael Meissner]

On Mon, Nov 01, 2021 at 10:56:33AM -0500, Bill Schmidt wrote:
> Would starting from Advance Toolchain 15 with the most recent glibc make things easier for Thomas to test?

The problem is gcc135 runs Centos 7.x which is not compatible with AT 13-15.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)

[Bernhard Reutner-Fischer]

Michael,

On Thu, 28 Oct 2021 23:36:20 -0400
Michael Meissner via Fortran <fortran@gcc.gnu.org> wrote:

ISTM the second
@defmac FORTRAN_USE_LONG_DOUBLE
in tm.texi.in should be FORTRAN_USE_FLOAT128

thanks,

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)

[Michael Meissner]

On Fri, Oct 29, 2021 at 11:21:33PM +0200, Bernhard Reutner-Fischer wrote:
> Michael,
> 
> On Thu, 28 Oct 2021 23:36:20 -0400
> Michael Meissner via Fortran <fortran@gcc.gnu.org> wrote:
> 
> ISTM the second
> @defmac FORTRAN_USE_LONG_DOUBLE
> in tm.texi.in should be FORTRAN_USE_FLOAT128

Thanks.  I had noticed that afterwards.  Note, the next patches will delete
those macros, because I discovered it was unworkable.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch)

[Michael Meissner]

This patch replaces the first patch.

Instead of disallowing long double and only dealing with float128 types, this
patch tries to accommodate the two.

It adds target hooks so the back end can overwrite the kind number for types.
I made the IBM long double type use KIND=15 instead of KIND=16, and Float128
uses KIND=16 as we've discussed.  The tests for long double are still
failing, so I suspect we will need some way of signalling about the long double
which uses a funky kind (king=15).

Again, this patch may be completely wild and crazy, as I don't really grok the
Fortran internals.  But perhaps it will help somebody to take the concepts and
come up with a more workable solution.

Note, the fleshing out of full F128 support is only partially done.  I
discovered that we don't have a complete set of FLOAT128 built-in functions
defined, so I couldn't just add code to DO_DEFINE_MATH_BUILTIN to make every
math function have the float128 counterpart declared.  Note, that code is
probably not used right now, since the float128 support uses the 'q' functions
in libquadmath.  Too fully utilize the f128 functions, you will need glibc 2.34
or later.

> From 80d617264d80eb86806aecb2db5f37adb9b37ff6 Mon Sep 17 00:00:00 2001
> From: Michael Meissner <meissner@linux.ibm.com>
> Date: Fri, 29 Oct 2021 18:35:42 -0400
> Subject: [PATCH] Second patch for PowerPC Fortran KIND=16.

This replaces the first patch, and it is a work in progress.  This patch
adds three target hooks to allow the backend to control the fortran KIND
numbers.  I have modified the PowerPC back end so that KIND==16 is always
IEEE 128-bit on systems support IEEE 128-bit, and KIND=15 is the long
double type if long double is IBM 128-bit.

gcc/

2021-10-29  Michael Meissner  <meissner@the-meissners.org>

	* config/rs6000/rs6000.c (TARGET_FORTRAN_REAL_KIND_NUMBER): Set
	target hook.
	(TARGET_FORTRAN_REAL_KIND_TYPE): Likewise.
	(TARGET_FORTRAN_REAL_KIND_FLOAT128_P): Likewise.
	(rs6000_fortran_real_kind_number): New target hook.
	(rs6000_fortran_real_kind_type): Likewise.
	(rs6000_fortran_real_kind_float128_p): Likewise.
	* target.def (fortran_real_kind_number): New target hook.
	(fortran_real_kind_type): Likewise.
	(fortran_real_kind_float128_p): Likewise.
	* targhooks.c (default_fortran_real_kind_number): New default
	target hooks for Fortran kind support.
	(default_fortran_real_kind_type): Likewise.
	(default_fortran_real_kind_float128_p): Likewise.
	* targhooks.h (default_fortran_real_kind_number): New
	declaration.
	(default_fortran_real_kind_type): Likewise.
	(default_fortran_real_kind_float128_p): Likewise.
	* tree.h (complex_float128_type_node): New define.
	* doc/tm.texi.in (TARGET_FORTRAN_REAL_KIND_*): Document new target
	hooks.
	* doc/tm.texi: Regenerate.

gcc/fortran/

2021-10-29  Michael Meissner  <meissner@the-meissners.org>

	* f95-lang.c (gfc_init_builtin_functions): Flesh out more Float128
	support.
	* trans-types.c (gfc_init_kinds): Add support for using target
	hooks to allow the backend to control KIND numbers.
	(gfc_build_real_type): Likewise.
	(gfc_build_complex_type): Add support for complex Float128.
---
 gcc/config/rs6000/rs6000.c | 101 +++++++++++++++++++++++++++++++++++++
 gcc/doc/tm.texi            |  17 +++++++
 gcc/doc/tm.texi.in         |   6 +++
 gcc/fortran/f95-lang.c     |  28 ++++++++++
 gcc/fortran/trans-types.c  |  32 ++++++++----
 gcc/target.def             |  22 +++++++-
 gcc/targhooks.c            |  37 ++++++++++++++
 gcc/targhooks.h            |   3 ++
 gcc/tree.h                 |   2 +
 9 files changed, 236 insertions(+), 12 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 22f5d701908..70595e58ac2 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -1787,6 +1787,15 @@ static const struct attribute_spec rs6000_attribute_table[] =
 
 #undef TARGET_INVALID_CONVERSION
 #define TARGET_INVALID_CONVERSION rs6000_invalid_conversion
+
+#undef TARGET_FORTRAN_REAL_KIND_NUMBER
+#define TARGET_FORTRAN_REAL_KIND_NUMBER rs6000_fortran_real_kind_number
+
+#undef TARGET_FORTRAN_REAL_KIND_TYPE
+#define TARGET_FORTRAN_REAL_KIND_TYPE rs6000_fortran_real_kind_type
+
+#undef TARGET_FORTRAN_REAL_KIND_FLOAT128_P
+#define TARGET_FORTRAN_REAL_KIND_FLOAT128_P rs6000_fortran_real_kind_float128_p
 \f
 
 /* Processor table.  */
@@ -28376,6 +28385,98 @@ rs6000_globalize_decl_name (FILE * stream, tree decl)
 }
 #endif
 
+\f
+
+/* PowerPC support for Fortran KIND support.  Given a MODE, return a kind
+   number to be used for real modes.  If we support IEEE 128-bit, make KIND=16
+   always be IEEE 128-bit, and make KIND=15 be the IBM 128-bit double-double
+   format.  */
+
+static int
+rs6000_fortran_real_kind_number (machine_mode mode)
+{
+  if (TARGET_FLOAT128_TYPE)
+    {
+      /* If long double is IEEE 128-bit, return 16 for long double and 15 for
+	 __ibm128, and ignore the explicit __float128 type.  Otherwise return
+	 15 for long double, 16 for __float128, and ignore __ibm128.  */
+      if (FLOAT128_IEEE_P (TFmode))
+	{
+	  if (mode == TFmode)
+	    return 16;
+	  else if (mode == IFmode)
+	    return 15;
+	}
+      else
+	{
+	  if (mode == KFmode)
+	    return 16;
+	  else if (mode == TFmode)
+	    return 15;
+	}
+    }
+
+  return 0;
+}
+
+/* PowerPC support for Fortran KIND support.  Return a type given a precision
+   that Fortran will handle for kind support.  We don't have to support the
+   standard types.  */
+static tree
+rs6000_fortran_real_kind_type (int precision)
+{
+  if (TARGET_FLOAT128_TYPE)
+    {
+      switch (precision)
+	{
+	case FLOAT_PRECISION_TFmode:
+	  return long_double_type_node;
+
+	case FLOAT_PRECISION_IFmode:
+	  return (FLOAT128_IBM_P (TFmode)
+		  ? long_double_type_node
+		  : ibm128_float_type_node);
+
+	case FLOAT_PRECISION_KFmode:
+	  return (FLOAT128_IEEE_P (TFmode)
+		  ? long_double_type_node
+		  : float128_type_node);
+
+	default:
+	  break;
+	}
+    }
+
+  return NULL_TREE;
+}
+
+/* PowerPC support for Fortran KIND support.  Return true given a precision for
+   a floating point scalar type that Fortran will handle for kind support.  We
+   don't have to handle the standard types here.  */
+static bool
+rs6000_fortran_real_kind_float128_p (int precision)
+{
+  if (TARGET_FLOAT128_TYPE)
+    {
+      switch (precision)
+	{
+	case FLOAT_PRECISION_TFmode:
+	  return FLOAT128_IEEE_P (TFmode);
+
+	case FLOAT_PRECISION_IFmode:
+	  return false;
+
+	case FLOAT_PRECISION_KFmode:
+	  return true;
+
+	default:
+	  break;
+	}
+    }
+
+  return NULL_TREE;
+}
+
 \f
 /* On 64-bit Linux and Freebsd systems, possibly switch the long double library
    function names from <foo>l to <foo>f128 if the default long double type is
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 902402d7503..e9743d791d2 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -12612,3 +12612,20 @@ counters are incremented using atomic operations.  Targets not supporting
 64-bit atomic operations may override the default value and request a 32-bit
 type.
 @end deftypefn
+
+@deftypefn {Target Hook} int TARGET_FORTRAN_REAL_KIND_NUMBER (machine_mode @var{mode})
+Returns an integer from a @code{MODE} that would be the Fortran kind
+number for target specific modes.  @code{MODE} is a scalar floating point
+mode.  If the mode cannot be represented, a 0 is returned.
+@end deftypefn
+
+@deftypefn {Target Hook} tree TARGET_FORTRAN_REAL_KIND_TYPE (int @var{precision})
+Returns a floating point scalar type with precision @code{PRECISION} that
+can be used for a Fortran kind type.  If the precision cannot be represented,
+a @code{NULL_TREE} is returned.
+@end deftypefn
+
+@deftypefn {Target Hook} bool TARGET_FORTRAN_REAL_KIND_FLOAT128_P (int @var{precision})
+Returns true if the floating point scalar type with precision
+@code{PRECISION} is an IEEE 128-bit floating point value.
+@end deftypefn
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 86352dc9bd2..28ae369e588 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -8187,3 +8187,9 @@ maintainer is familiar with.
 @hook TARGET_MEMTAG_UNTAGGED_POINTER
 
 @hook TARGET_GCOV_TYPE_SIZE
+
+@hook TARGET_FORTRAN_REAL_KIND_NUMBER
+
+@hook TARGET_FORTRAN_REAL_KIND_TYPE
+
+@hook TARGET_FORTRAN_REAL_KIND_FLOAT128_P
diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
index 58dcaf01d75..b8117dc72b4 100644
--- a/gcc/fortran/f95-lang.c
+++ b/gcc/fortran/f95-lang.c
@@ -674,9 +674,11 @@ gfc_init_builtin_functions (void)
   tree mfunc_float[6];
   tree mfunc_double[6];
   tree mfunc_longdouble[6];
+  tree mfunc_float128[6];
   tree mfunc_cfloat[6];
   tree mfunc_cdouble[6];
   tree mfunc_clongdouble[6];
+  tree mfunc_cfloat128[6];
   tree func_cfloat_float, func_float_cfloat;
   tree func_cdouble_double, func_double_cdouble;
   tree func_clongdouble_longdouble, func_longdouble_clongdouble;
@@ -691,9 +693,11 @@ gfc_init_builtin_functions (void)
   build_builtin_fntypes (mfunc_float, float_type_node);
   build_builtin_fntypes (mfunc_double, double_type_node);
   build_builtin_fntypes (mfunc_longdouble, long_double_type_node);
+  build_builtin_fntypes (mfunc_float128, float128_type_node);
   build_builtin_fntypes (mfunc_cfloat, complex_float_type_node);
   build_builtin_fntypes (mfunc_cdouble, complex_double_type_node);
   build_builtin_fntypes (mfunc_clongdouble, complex_long_double_type_node);
+  build_builtin_fntypes (mfunc_cfloat128, complex_float128_type_node);
 
   func_cfloat_float = build_function_type_list (float_type_node,
                                                 complex_float_type_node,
@@ -736,6 +740,8 @@ gfc_init_builtin_functions (void)
 
   gfc_define_builtin ("__builtin_roundl", mfunc_longdouble[0], 
 		      BUILT_IN_ROUNDL, "roundl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  gfc_define_builtin ("__builtin_roundf128", mfunc_float128[0], 
+		      BUILT_IN_ROUNDF128, "roundf128", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_round", mfunc_double[0], 
 		      BUILT_IN_ROUND, "round", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_roundf", mfunc_float[0], 
@@ -743,6 +749,8 @@ gfc_init_builtin_functions (void)
 
   gfc_define_builtin ("__builtin_truncl", mfunc_longdouble[0],
 		      BUILT_IN_TRUNCL, "truncl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  gfc_define_builtin ("__builtin_truncf128", mfunc_float128[0],
+		      BUILT_IN_TRUNCF128, "truncl", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_trunc", mfunc_double[0],
 		      BUILT_IN_TRUNC, "trunc", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_truncf", mfunc_float[0],
@@ -750,6 +758,7 @@ gfc_init_builtin_functions (void)
 
   gfc_define_builtin ("__builtin_cabsl", func_clongdouble_longdouble, 
 		      BUILT_IN_CABSL, "cabsl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_cabsf128.  */
   gfc_define_builtin ("__builtin_cabs", func_cdouble_double, 
 		      BUILT_IN_CABS, "cabs", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_cabsf", func_cfloat_float, 
@@ -758,6 +767,9 @@ gfc_init_builtin_functions (void)
   gfc_define_builtin ("__builtin_copysignl", mfunc_longdouble[1], 
 		      BUILT_IN_COPYSIGNL, "copysignl",
 		      ATTR_CONST_NOTHROW_LEAF_LIST);
+  gfc_define_builtin ("__builtin_copysignf128", mfunc_longdouble[1], 
+		      BUILT_IN_COPYSIGNF128, "copysignf128",
+		      ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_copysign", mfunc_double[1], 
 		      BUILT_IN_COPYSIGN, "copysign",
 		      ATTR_CONST_NOTHROW_LEAF_LIST);
@@ -768,6 +780,7 @@ gfc_init_builtin_functions (void)
   gfc_define_builtin ("__builtin_nextafterl", mfunc_longdouble[1], 
 		      BUILT_IN_NEXTAFTERL, "nextafterl",
 		      ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_nextafterf128.  */
   gfc_define_builtin ("__builtin_nextafter", mfunc_double[1], 
 		      BUILT_IN_NEXTAFTER, "nextafter",
 		      ATTR_CONST_NOTHROW_LEAF_LIST);
@@ -781,6 +794,8 @@ gfc_init_builtin_functions (void)
 
   gfc_define_builtin ("__builtin_rintl", mfunc_longdouble[0], 
 		      BUILT_IN_RINTL, "rintl", attr);
+  gfc_define_builtin ("__builtin_rintf128", mfunc_float128[0], 
+		      BUILT_IN_RINTF128, "rintf128", attr);
   gfc_define_builtin ("__builtin_rint", mfunc_double[0], 
 		      BUILT_IN_RINT, "rint", attr);
   gfc_define_builtin ("__builtin_rintf", mfunc_float[0], 
@@ -788,6 +803,7 @@ gfc_init_builtin_functions (void)
 
   gfc_define_builtin ("__builtin_remainderl", mfunc_longdouble[1], 
 		      BUILT_IN_REMAINDERL, "remainderl", attr);
+  /* no __builtin_remainderf128.  */
   gfc_define_builtin ("__builtin_remainder", mfunc_double[1], 
 		      BUILT_IN_REMAINDER, "remainder", attr);
   gfc_define_builtin ("__builtin_remainderf", mfunc_float[1], 
@@ -795,6 +811,7 @@ gfc_init_builtin_functions (void)
  
   gfc_define_builtin ("__builtin_logbl", mfunc_longdouble[0], 
 		      BUILT_IN_LOGBL, "logbl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_logbf128.  */
   gfc_define_builtin ("__builtin_logb", mfunc_double[0], 
 		      BUILT_IN_LOGB, "logb", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_logbf", mfunc_float[0], 
@@ -803,6 +820,7 @@ gfc_init_builtin_functions (void)
 
   gfc_define_builtin ("__builtin_frexpl", mfunc_longdouble[4], 
 		      BUILT_IN_FREXPL, "frexpl", ATTR_NOTHROW_LEAF_LIST);
+  /* no __builtin_frexpf128.  */
   gfc_define_builtin ("__builtin_frexp", mfunc_double[4], 
 		      BUILT_IN_FREXP, "frexp", ATTR_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_frexpf", mfunc_float[4], 
@@ -810,6 +828,8 @@ gfc_init_builtin_functions (void)
  
   gfc_define_builtin ("__builtin_fabsl", mfunc_longdouble[0], 
 		      BUILT_IN_FABSL, "fabsl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  gfc_define_builtin ("__builtin_fabsf128", mfunc_float128[0], 
+		      BUILT_IN_FABSF128, "fabsf128", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_fabs", mfunc_double[0], 
 		      BUILT_IN_FABS, "fabs", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_fabsf", mfunc_float[0], 
@@ -817,6 +837,7 @@ gfc_init_builtin_functions (void)
  
   gfc_define_builtin ("__builtin_scalbnl", mfunc_longdouble[2],
 		      BUILT_IN_SCALBNL, "scalbnl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_scalbnf128.  */
   gfc_define_builtin ("__builtin_scalbn", mfunc_double[2],
 		      BUILT_IN_SCALBN, "scalbn", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_scalbnf", mfunc_float[2],
@@ -824,6 +845,7 @@ gfc_init_builtin_functions (void)
  
   gfc_define_builtin ("__builtin_fmodl", mfunc_longdouble[1], 
 		      BUILT_IN_FMODL, "fmodl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_fmodf128.  */
   gfc_define_builtin ("__builtin_fmod", mfunc_double[1], 
 		      BUILT_IN_FMOD, "fmod", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_fmodf", mfunc_float[1], 
@@ -872,18 +894,21 @@ gfc_init_builtin_functions (void)
   /* These are used to implement the ** operator.  */
   gfc_define_builtin ("__builtin_powl", mfunc_longdouble[1], 
 		      BUILT_IN_POWL, "powl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_powf128.  */
   gfc_define_builtin ("__builtin_pow", mfunc_double[1], 
 		      BUILT_IN_POW, "pow", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_powf", mfunc_float[1], 
 		      BUILT_IN_POWF, "powf", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_cpowl", mfunc_clongdouble[1], 
 		      BUILT_IN_CPOWL, "cpowl", ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_cpowf128.  */
   gfc_define_builtin ("__builtin_cpow", mfunc_cdouble[1], 
 		      BUILT_IN_CPOW, "cpow", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_cpowf", mfunc_cfloat[1], 
 		      BUILT_IN_CPOWF, "cpowf", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_powil", mfunc_longdouble[2],
 		      BUILT_IN_POWIL, "powil", ATTR_CONST_NOTHROW_LEAF_LIST);
+  /* no __builtin_powif128.  */
   gfc_define_builtin ("__builtin_powi", mfunc_double[2],
 		      BUILT_IN_POWI, "powi", ATTR_CONST_NOTHROW_LEAF_LIST);
   gfc_define_builtin ("__builtin_powif", mfunc_float[2],
@@ -895,6 +920,7 @@ gfc_init_builtin_functions (void)
       gfc_define_builtin ("__builtin_cbrtl", mfunc_longdouble[0],
 			  BUILT_IN_CBRTL, "cbrtl",
 			  ATTR_CONST_NOTHROW_LEAF_LIST);
+      /* no __builtin_cbrtf128.  */
       gfc_define_builtin ("__builtin_cbrt", mfunc_double[0],
 			  BUILT_IN_CBRT, "cbrt",
 			  ATTR_CONST_NOTHROW_LEAF_LIST);
@@ -904,6 +930,7 @@ gfc_init_builtin_functions (void)
       gfc_define_builtin ("__builtin_cexpil", func_longdouble_clongdouble, 
 			  BUILT_IN_CEXPIL, "cexpil",
 			  ATTR_CONST_NOTHROW_LEAF_LIST);
+      /* no __builtin_cexpif128.  */
       gfc_define_builtin ("__builtin_cexpi", func_double_cdouble,
 			  BUILT_IN_CEXPI, "cexpi",
 			  ATTR_CONST_NOTHROW_LEAF_LIST);
@@ -917,6 +944,7 @@ gfc_init_builtin_functions (void)
       gfc_define_builtin ("__builtin_sincosl",
 			  func_longdouble_longdoublep_longdoublep,
 			  BUILT_IN_SINCOSL, "sincosl", ATTR_NOTHROW_LEAF_LIST);
+      /* no __builtin_sincosf128.  */
       gfc_define_builtin ("__builtin_sincos", func_double_doublep_doublep,
 			  BUILT_IN_SINCOS, "sincos", ATTR_NOTHROW_LEAF_LIST);
       gfc_define_builtin ("__builtin_sincosf", func_float_floatp_floatp,
diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index 1c78a906397..4b2885de3f1 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -451,14 +451,6 @@ gfc_init_kinds (void)
 	 useless.  */
       if (!targetm.libgcc_floating_mode_supported_p (mode))
 	continue;
-      if (mode != TYPE_MODE (float_type_node)
-	    && (mode != TYPE_MODE (double_type_node))
-	    && (mode != TYPE_MODE (long_double_type_node))
-#if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT)
-	    && (mode != TFmode)
-#endif
-	   )
-	continue;
 
       /* Let the kind equal the precision divided by 8, rounding up.  Again,
 	 this insulates the programmer from the underlying byte size.
@@ -480,7 +472,9 @@ gfc_init_kinds (void)
 	 reach this code.
       */
 
-      kind = (GET_MODE_PRECISION (mode) + 7) / 8;
+      kind = targetm.fortran_real_kind_number (mode);
+      if (kind == 0)
+	kind = (GET_MODE_PRECISION (mode) + 7) / 8;
 
       if (kind == 4)
 	saw_r4 = true;
@@ -856,12 +850,26 @@ gfc_build_real_type (gfc_real_info *info)
     info->c_double = 1;
   if (mode_precision == LONG_DOUBLE_TYPE_SIZE)
     info->c_long_double = 1;
-  if (mode_precision != LONG_DOUBLE_TYPE_SIZE && mode_precision == 128)
-    {
+
+#if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT)
+  if (TYPE_PRECISION (float128_type_node) == mode_precision)
+   {
       /* TODO: see PR101835.  */
       info->c_float128 = 1;
       gfc_real16_is_float128 = true;
     }
+#endif
+
+  tree type = targetm.fortran_real_kind_type (mode_precision);
+  if (type)
+    {
+      if (type == float128_type_node)
+	{
+	  info->c_float128 = 1;
+	  gfc_real16_is_float128 = true;
+	}
+      return type;
+    }
 
   if (TYPE_PRECISION (float_type_node) == mode_precision)
     return float_type_node;
@@ -889,6 +897,8 @@ gfc_build_complex_type (tree scalar_type)
     return complex_double_type_node;
   if (scalar_type == long_double_type_node)
     return complex_long_double_type_node;
+  if (scalar_type == float128_type_node)
+    return complex_float128_type_node;
 
   new_type = make_node (COMPLEX_TYPE);
   TREE_TYPE (new_type) = scalar_type;
diff --git a/gcc/target.def b/gcc/target.def
index c5d90cace80..308649779fa 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -7129,6 +7129,26 @@ counters are incremented using atomic operations.  Targets not supporting\n\
 type.",
  HOST_WIDE_INT, (void), default_gcov_type_size)
 
-/* Close the 'struct gcc_target' definition.  */
+DEFHOOK
+(fortran_real_kind_number,
+ "Returns an integer from a @code{MODE} that would be the Fortran kind\n\
+number for target specific modes.  @code{MODE} is a scalar floating point\n\
+mode.  If the mode cannot be represented, a 0 is returned.",
+ int, (machine_mode mode), default_fortran_real_kind_number)
+
+DEFHOOK
+(fortran_real_kind_type,
+ "Returns a floating point scalar type with precision @code{PRECISION} that\n\
+can be used for a Fortran kind type.  If the precision cannot be represented,\n\
+a @code{NULL_TREE} is returned.",
+ tree, (int precision), default_fortran_real_kind_type)
+
+DEFHOOK
+(fortran_real_kind_float128_p,
+ "Returns true if the floating point scalar type with precision\n\
+@code{PRECISION} is an IEEE 128-bit floating point value.",
+ bool, (int precision), default_fortran_real_kind_float128_p)
+
+ /* Close the 'struct gcc_target' definition.  */
 HOOK_VECTOR_END (C90_EMPTY_HACK)
 
diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index cbbcedf790f..cc15539ffdb 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -2661,4 +2661,41 @@ default_gcov_type_size (void)
   return TYPE_PRECISION (long_long_integer_type_node) > 32 ? 64 : 32;
 }
 
+/* The default implementation of TARGET_FORTRAN_REAL_KIND_NUMBER.  */
+
+int
+default_fortran_real_kind_number (machine_mode mode ATTRIBUTE_UNUSED)
+{
+#if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT)
+  if (mode == TFmode)
+    return GET_MODE_SIZE (TFmode);
+#endif
+
+  return 0;
+}
+
+/* The default implementation of TARGET_FORTRAN_REAL_KIND_TYPE.  */
+tree
+default_fortran_real_kind_type (int precision ATTRIBUTE_UNUSED)
+{
+#if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT)
+  if (precision == TYPE_PRECISION (float128_type_node))
+    return float128_type_node;
+#endif
+
+  return NULL_TREE;
+}
+
+/* The default implementation of TARGET_FORTRAN_REAL_KIND_FLOAT128_p.  */
+bool
+default_fortran_real_kind_float128_p (int precision ATTRIBUTE_UNUSED)
+{
+#if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT)
+  if (precision == TYPE_PRECISION (float128_type_node))
+    return true;
+#endif
+
+  return false;
+}
+
 #include "gt-targhooks.h"
diff --git a/gcc/targhooks.h b/gcc/targhooks.h
index 92d51992e62..c5f9cd08450 100644
--- a/gcc/targhooks.h
+++ b/gcc/targhooks.h
@@ -304,4 +304,7 @@ extern rtx default_memtag_untagged_pointer (rtx, rtx);
 
 extern HOST_WIDE_INT default_gcov_type_size (void);
 
+extern int default_fortran_real_kind_number (machine_mode);
+extern tree default_fortran_real_kind_type (int);
+extern bool default_fortran_real_kind_float128_p (int);
 #endif /* GCC_TARGHOOKS_H */
diff --git a/gcc/tree.h b/gcc/tree.h
index 7542d97ce12..f3b47f81a09 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -4225,6 +4225,8 @@ tree_strip_any_location_wrapper (tree exp)
 #define complex_double_type_node	global_trees[TI_COMPLEX_DOUBLE_TYPE]
 #define complex_long_double_type_node	global_trees[TI_COMPLEX_LONG_DOUBLE_TYPE]
 
+#define complex_float128_type_node	global_trees[TI_COMPLEX_FLOAT128_TYPE]
+
 #define COMPLEX_FLOATN_NX_TYPE_NODE(IDX)	global_trees[TI_COMPLEX_FLOATN_NX_TYPE_FIRST + (IDX)]
 
 #define void_type_node			global_trees[TI_VOID_TYPE]
-- 
2.31.1



-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch)

[Thomas Koenig]

Hi Michael,

> It adds target hooks so the back end can overwrite the kind number for types.
> I made the IBM long double type use KIND=15 instead of KIND=16, and Float128
> uses KIND=16 as we've discussed.  The tests for long double are still
> failing, so I suspect we will need some way of signalling about the long double
> which uses a funky kind (king=15).

There is still no conclusion how to deal with the two 16-bit types.  I
have also asked on the J3 mailing list, and received a few different
opinions and options as well.

We can:

- Support KIND=16 == IEEE_QP only in the compiler, and supply a CONVERT
   option from IBM_QP to IEEE_QP only.  People who would need the old
   format (why anybody would do that, I have no idea, but some may)
   would have to use the old compiler.

- Support KIND=16 == IEEE_QP and KIND=15 = IBM_QP in the compiler, and
   implement SELECTED_REAL_KIND according to the Fortran standard.  This
   would mean that people who put in a precision of 20 digits as a
   shorthand for REAL(KIND=16) will get the old version.  This will
   lead to endless confusion, and penalize people who used
   SELECTED_REAL_KIND, so it should be avoided.

- Support KIND=16 == IEEE_QP and KIND=15 = IBM_QP in the compiler, and
   have SELECTED_REAL_KIND return 16 for anything above double precision.
   This would actually violate the Fortran standard, and has been
   generally viewed by J3 as not a good idea.  It would, however, work
   well for most users.  Those who actually need IBM_QP would have to
   specify it specifically.

- Have a compiler switch which selects between IEEE_QP and IBM_QP.
   This was a suggestion by Steve Lionel formerly of DEC and Intel,
   and they did that when they had a few floating point formats on
   the Alpha to choose from.  We would then have to specially annotate
   the KIND=16 library routines, and also maybe indicate the different
   argument types in module files.  Anything else would be user error.
   They also had the CONVERT options to go with it.

Question: Which option would we want to pursue?  I actually think the
fourth one (the suggestion by Steve Lionel) is the best one.

Other opinions?

Best regards

	Thomas

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch)

[Jakub Jelinek]

On Sat, Oct 30, 2021 at 11:30:29AM +0200, Thomas Koenig wrote:
> - Have a compiler switch which selects between IEEE_QP and IBM_QP.
>   This was a suggestion by Steve Lionel formerly of DEC and Intel,
>   and they did that when they had a few floating point formats on
>   the Alpha to choose from.  We would then have to specially annotate
>   the KIND=16 library routines, and also maybe indicate the different
>   argument types in module files.  Anything else would be user error.
>   They also had the CONVERT options to go with it.
> 
> Question: Which option would we want to pursue?  I actually think the
> fourth one (the suggestion by Steve Lionel) is the best one.

That was the last option I was mentioning in the initial mail
https://gcc.gnu.org/pipermail/gcc/2021-October/237478.html

Copying it here:

Or the last option would be to try to make libgfortran.so.5 ABI compatible
with both choices on powerpc64le-linux.  From quick skimming of libgfortran,
we have lots of generated functions, which use HAVE_GFC_REAL_16 and
GFC_REAL_16 etc. macros.  So, we could perhaps arrange for the compiler
to use r16i or r17 instead of r16 in the names when real(kind=16) is the
IEEE quad on powerpc64le and keep using r16 for the IBM double double.
For the *.F90 generated files, one could achieve it by making sure
the *r16* files are compiled with -mabi=ibmlongdouble, for
*r16i* or *r17* with -mabi=ieeelongdouble and otherwise use kind=16 in
those, for *.c generated files the *GFC_* macros could just ensure that
it doesn't use long double but __ibm128 or __float128 depending on which one
is needed.
But then I see e.g. the io routines to just pass in kind and so
switch (kind) // or len
  {
  case ...:
    *(GFC_REAL_*) = ...;
  }
etc.  Could we just pretend in the compiler to libgfortran ABI that
powerpc64le-linux real(kind=16) is kind 17 and make sure that if anything
would actually think it is 17 bytes it uses 16 instead (though, kind=10
on x86-64 or i686 also isn't 10 bytes but 16 or 12, right?).

That solution would most closely match what we do e.g. for C/C++, especially
libstdc++ or glibc, we already have an option to select that -
-mabi=ibmlongdouble vs. -mabi=ieeelongdouble and default selected during
configure.  libgfortran would be ABI compatible with both ABIs, but user
binaries or libraries wouldn't be.  Similarly to C, there is no different
mangling of user symbols.

	Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch)

[Thomas Koenig]

Hi Jakub,

> On Sat, Oct 30, 2021 at 11:30:29AM +0200, Thomas Koenig wrote:
>> - Have a compiler switch which selects between IEEE_QP and IBM_QP.
>>    This was a suggestion by Steve Lionel formerly of DEC and Intel,
>>    and they did that when they had a few floating point formats on
>>    the Alpha to choose from.  We would then have to specially annotate
>>    the KIND=16 library routines, and also maybe indicate the different
>>    argument types in module files.  Anything else would be user error.
>>    They also had the CONVERT options to go with it.
>>
>> Question: Which option would we want to pursue?  I actually think the
>> fourth one (the suggestion by Steve Lionel) is the best one.
> 
> That was the last option I was mentioning in the initial mail
> https://gcc.gnu.org/pipermail/gcc/2021-October/237478.html
> 
> Copying it here:
> 
> Or the last option would be to try to make libgfortran.so.5 ABI compatible
> with both choices on powerpc64le-linux.  From quick skimming of libgfortran,
> we have lots of generated functions, which use HAVE_GFC_REAL_16 and
> GFC_REAL_16 etc. macros.  So, we could perhaps arrange for the compiler
> to use r16i or r17 instead of r16 in the names when real(kind=16) is the
> IEEE quad on powerpc64le and keep using r16 for the IBM double double.

That is quite doable.

> For the *.F90 generated files, one could achieve it by making sure
> the *r16* files are compiled with -mabi=ibmlongdouble, for
> *r16i* or *r17* with -mabi=ieeelongdouble and otherwise use kind=16 in
> those, for *.c generated files the *GFC_* macros could just ensure that
> it doesn't use long double but __ibm128 or __float128 depending on which one
> is needed.

Yep.

> But then I see e.g. the io routines to just pass in kind and so
> switch (kind) // or len
>    {
>    case ...:
>      *(GFC_REAL_*) = ...;
>    }
> etc.  Could we just pretend in the compiler to libgfortran ABI that
> powerpc64le-linux real(kind=16) is kind 17 and make sure that if anything
> would actually think it is 17 bytes it uses 16 instead (though, kind=10
> on x86-64 or i686 also isn't 10 bytes but 16 or 12, right?).

That is not something I would like to have, for purposes of cleanness.
We can always switch at run-time to a different function.  This
branch should be rather well-predicted, and additional execution
will be insignificant compared to the rest of the I/O.

> 
> That solution would most closely match what we do e.g. for C/C++, especially
> libstdc++ or glibc, we already have an option to select that -
> -mabi=ibmlongdouble vs. -mabi=ieeelongdouble and default selected during
> configure.  libgfortran would be ABI compatible with both ABIs, but user
> binaries or libraries wouldn't be.  Similarly to C, there is no different
> mangling of user symbols.

Hm, there's a difference.  I meant that we can select this at compile
time for the user, and we should at least consider adding a flag to
the module files if the routine has been compiled for IBM_QP or IEEE_QP.
We should not change the mangling of the routine names themselves,
I agree.

Best regards

	Thomas