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