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
