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

[Thomas Koenig <tkoenig@netcologne.de>]

On 16.11.21 00:42, Michael Meissner wrote:
> 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.

That is where I come in, I think.

> 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.

OK.

Looking at a random sample, libgfortran/generated/maxloc0_4_r4.c , has

#if defined (HAVE_GFC_REAL_4) && defined (HAVE_GFC_INTEGER_4)

extern void maxloc0_4_r4 (gfc_array_i4 * const restrict retarray,
         gfc_array_r4 * const restrict array, GFC_LOGICAL_4);

which is expanded by m4 from maxloc0.m4, which in turn includes
iforeach.m4, which has

name`'rtype_qual`_'atype_code (rtype * const restrict retarray,
         atype * const restrict array, GFC_LOGICAL_4 back)

where the parameters are determined from the file name.  So we
can put in a file maxloc0_4_r17 into the normal build process,
which will give us

#if defined (HAVE_GFC_REAL_17) && defined (HAVE_GFC_INTEGER_4)

Next thing to do would be to put the file into libgfortran/Makefile.am,
making sure that it is compiled with the right options.  There will
have to be some condition on the compilation that we do not compile
the files on non-POWER-systems.

Next, we need to define GFC_REAL_17 as IEEE QP on POWER (only there
of course), probably in libgfortran/kinds-override.h.

For compiling, there has to be a flag in the compiler to let us
know what we are compiling for, so we can call the different
functions depending on the flag.

> 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.

Yep.

> 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.

I can start working on that, once the following are in (or documented):

- A global configure script that determines if there is a target which
   supports both IEEE QP and double double.

- A conditional suitable for Makefile.am on libgfortran to check for
   that condition

- A preprocessor directive in the compiler to check if IEEE and
   QP are supported with the right flag

- A compiler flag to select either IEEE QP or double double as default

- A global flag to check if IEEE or double double is enabled



>> 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.

I'd say we would need a global reviewer's OK for that, plus of course
from a POWER maintainer, but that should not be a problem :-)

> 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.

If you could start working on the points above, that would be great.

Best regards

	Thomas