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