Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Michael Meissner <meissner@linux.ibm.com>]

On Mon, Nov 15, 2021 at 09:27:38PM +0100, Thomas Koenig wrote:
> Hi,
> 
> is there an update on this?  I am still waiting on a response for
> the account on the development machine.
> 
> I assume we would to the development on a branch.  My git fu
> is extremely weak, so I would appreciate if somebody did that
> for me.

Sure, we can create an IBM vendor branch.

> Is it actually possible to implement what I wrote in the draft
> documentation patch, or is there some problem (like gmp
> or mpfr depending on one of the types at compile-time)?
> 
> If so, I think we should go for it; if not, then we have to make
> another decision.

Well there are a couple of things that need to be done.  A lot are fortran
specific type things, so while I can attempt to do these things, I don't know
the structure of the front end or library.

From my previous test patches, I think it is a disaster if KIND=16 is not the
same as C/C++ long double by default.  It opens up all sorts of problems.  But
then it may be the Fortran users would like that flexibility.  That is your
call.

I think the most important thing is defining the library interface and naming
scheme.  So we need to switch calls to one name or another based on the default
long double format.  I don't know what naming scheme you use, but it should be
fairly simple.

For the C/C++/math built-ins, we use the traditional name with an 'l' suffix if
long double is IBM double-double, and a 'f128' suffix if long double is IEEE
128-bit.  The PowerPC backend will automatically switch names for built-ins it
knows about.

However, my tests showed there are a bunch of functions that are in the math
library that are not built-ins.  For C/C++, this is not an issue, because
math.h will do this switching.  We would need some way for Fortran to do it for
the other functions.

Once we have the naming scheme, then we need to modify the library build, so
that it will build both types of modules with the appropriate flags.

Once the library is set up to have both names, then we can start to think about
the user overriding the defaults.  This is probably a thing that needs the
Fortran folk to do, since there may be various rules of what can be done.  But
for the initial work, I think the most important thing is getting the library
so it has both names in it, so a user/distro could start to move the default
floating point type.

> Due to my day job, my time for working on this project is rather
> limited, and in my experience it is easier to finish something if
> it is actually started :-)
> 
> So, who does what?  I work on the gfortran internals (library interface)
> and the library itself, but I would need some prior work to set up the
> compiler so things work up to that particular point.
> 
> Or have we missed the window due to gcc being in stage 3 now?

This may be an issue for the release and Fortran maintainers.  Even if we can't
put it in right now, I think it is important to start work so it can be put in
at a later date.

In terms of my schedule, I will be available for doing whatever is needed until
December 20th.  I have a hard stop then as I will be doing a family trip for
Christmas and I will not be available after that.  I won't be back until the
new year.  I believe Bill and Peter feel this is one of the most important uses
of my time in the next month or so.  But bear in mind, I don't know much about
the Fortran front end, nothing about the library, or knowing Fortran at all.

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