On Sat, Aug 08, 2020 at 03:33:51PM +0200, Thomas König wrote: > Hi Michael, > > I have shortened the distribution list somewhat for the Fortran-relevant > parts. > > >I want to discuss changes that I think we need to make across the open source > >toochain to allow us to change the long double type on PowerPC hardware from > >using the IBM extended double (i.e. a pair of doubles) to the IEEE 128-bit > >format defined in IEEE 754. > > > >I wasn't sure whom to address this to, so I took a scatter shot approach. I > >likely missed a few people, and some people were added that may not need to > >participate in the discussion. Sorry for either not including you initially > >or > >for including you by mistake. > > > >I added people from the following areas: > > > > PowerPC folk > > > > Langugage maintainers: At the moment, only the C/C++ front ends have > > code to support both 128-bit floating point types. The other languages > > use just the defaults provided by the machine maintainers. However, it > > may be we will need to think about rules for code being compiled and > > linked with a different long double format. > > Currently, we support the IBM format with gfortran. So, we have to > look at a) library code called from user routines, and b) user code > compiled with one version calling another.
I have patches I'm working through that allows the whole toolchain to be built with the new default, and I have run through the C, C++, and Fortran test suites with a new version of glibc. In fact there were 2-3 tests that traditionally fail with IBM extended double that now pass. IMHO, changing the default is only appropriate for times like a distribution major number changes, where backwards and forwards compatibility is carefully controlled. But before we can contemplate doing this, we need the ability to change the default and have it all work together. In this case, there were no modifications to the gfortran sources. It is all controlled from the rs6000 backend gcc and libgcc machine specific functions. But there is no backwards compatibility if the user used explicit long double (in C/C++) or real*16 (gfortran). One of the keys is changing the names of the built-in functions. Glibc in math.h changes all of the long double functions it declares to be either the IBM extended double or IEEE 128-bit versions of the functions. Similarly Libstdc++ is in the middle of doing the changes for tht as well. In addition, the GNU compiler will change the external names of the built-in functions to be the IEEE 128-bit names. This allows for C/C++ users to not use math.h and still get the right function called (there were a few tests in the test suite that had to be fixed). It also allows Gfortran to use these functions by default. > > As for a), this is something that can be done using the right m4 > macros. We might even, with some hackery, be able to provide two > versions of the functions with the new library. Glibc and Libstdc++ are doing this right now. Tulio, Carlos can speak of glibc, and Johnathon can speak of libstdc++'s efforts. Generally in a mixed library approach, you provide both names, and you do not use long double, instead you use the explicit types (__ibm128 and __float128) for the two formats. Typically they use the -mno-gnu-attributes option which says to disable the gnu attributes that we use to mark which type of long double is used, so that it can be linked with either ABI. > For b), I do not have a clear solution for Fortran. But I also have > no idea how this is supposed to work in other languages, > when a user uses code compiles something with "long double" > with gcc 10 and links it against "long double" with gcc 11 - > what are your plans for that? > > It would be possible to annotate every function with calls long double > with the new format somehow (ugh), or you could make a clear ABI break. > This would mean a new, incompatible version of libgfortran, but we would > have to restrict that to POWER (would that be possible?). > We cannot impose an ABI change on everybody else to this. We do annotate each function that has long double arguments or returns long double arguments already with gnu attributes. There are some issues with it, and I want to delve into it deeper. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
