Fortran and real*16 on PowerPC and moving to IEE 128-bit

[Michael Meissner]

Note, generally I assume disclaimers, but just to be clear, in this context I
am speaking with my own opinion, and not an official opinion of IBM or any
other entity like a distribution.  While I work with the GLIBC folk, I also
can't speak for what they are doing.

I wanted to open up a dialog so that we can think of allowing people that need
IEEE 128-bit code can use it before a full fledged distro that has everything
by default is shipped.

On Sat, Oct 27, 2018 at 10:52:26PM +0300, Janne Blomqvist wrote:
> On Fri, Oct 26, 2018 at 12:25 AM Michael Meissner <meissner@linux.ibm.com>
> wrote:
> 
> > So with the GLIBC work progressing, it is time to start thinking about how
> > we
> > can move fortran's real*16 to use the IEEE 128-bit type.
> >
> > There are two basic methods that I know about:
> >
> >     1)  Wait for a distro to move, and fortran (in theory) should pick up
> > all
> >         of the changes for free, but that can take awhile;
> >
> 
> So does this mean that distros are going to have a flag day where they drop
> the old double-double format and switch to ieee? So we don't need to
> consider a situation where a system supports both?

This is up to the distros, but for the three main distros (Red Hat, Suse,
Ubuntu), I believe they do not want to go back a multilib approach where 2 or
more sets of libraries are delivered.

So either there will be a flag day (generally with a major version switch)
where the default is changed, or it will never change.

I believe GLIBC and Libstdc++ are both working adding compatibility layers so
that old code will continue to link when the default is switched.  And once the
GLIBC changes are done, users will be able to compile new code with the
appropriate option (-mabi=ieeelongdouble or -mabi=ibmlongdouble) to control the
format of long double/real*16.

> 
> >     2)  Add support within fortran to change the name used for real*16
> > support
> >         functions, and provide both functions in the library (this is what
> > C++
> >         is doing).
> >
> 
> .. and this means that we'd support both via, say, a compile-time switch,
> and thus the libgfortran must support both? In this case, glibc also
> provides both ABIs?

Work is underway for GLIBC.  However, this all depends on the C/C++ user using
the standard header files (math.h, stdio.h, etc.).  But fortran doesn't use the
C math.h, so it will be some amount of support that will be needed.

> > I just recently put in a patch to the rs6000 backend that switches the
> > names of
> > the math built-in functions if the compiler was configured for IBM extended
> > double and the user asked for IEEE 128-bit floating point, and this will
> > work
> > for fortran also.
> 
> 
> Looking at the cauldron videos, there was discussion about (some?) of the
> glibc IEEE f128 support being done via header magic, which would be a
> problem for GFortran which calls the functions directly without parsing the
> headers. So does this above patch address this issue?
> 
> 
> > We talked about me providing a patch to switch the libquad math functions
> > to
> > the GLIBC f128 functions, and after I implemented it, I realized that we
> > never
> > call the libquad math functions in PowerPC, because of IBM extended double
> > (and
> > there can only be one float type of a given size, which has made implement
> > the
> > IEEE 128-bit support so much 'fun').
> >
> > If we did call libquadmath, it would have been useful to switch to GLIBC's
> > f128
> > math functions, since these functions are being heavily optimized.
> 
> 
> IIRC there was some discussion here on the lists about the future of
> libquadmath, now that glibc has implemented f128 support for x86.  The
> problem is that we still need libquadmath for non-glibc targets, and it
> remains to be seen whether glibc improvements will propagate back to
> quadmath.  And also, on targets with new enough glibc, should Fortran
> switch to calling the glibc functions directly, or should the libquadmath
> compilation be changed to just provide aliases for the glibc functions if
> available, etc.
> 
> Ugh, but anyway, that's not per se related to ppc64le.

Yep.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.ibm.com, phone: +1 (978) 899-4797