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
