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