[RFC] Quad-float support for gfortran

[FX <fxcoudert at gmail dot com>]

Dear gfortranners,

For some work-related issue, I find the need to switch my code regularly between double precision real arithmetics and quad-float. I currently do that with a proprietary compiler whose brand name matches the regexp "^In{1,}[t]\x65l$", but I'd be even more happy to do that with gfortran (my usual compiler) and that gives me an excuse to get to do something I've long wanted to achieve for fun: quad-float integration in gfortran.

(To be clear, what I call above and in the following "quad-precision float" is the IEEE 754 binary128 floating-point type, known in GCC as the __float128 type.)


As I understand, the items to be sorted out in order to achieve this are:

  -- front-end support 1: the front-end needs to accept the real(kind=16) type (and complex accordingly) when __float128 is available as TFmode. This one is easy (it used to be available before I turned it off some years ago).

  -- front-end support 2: intrinsics need to be 

  -- libgfortran configuration: libfortran assumes that real(4) is float, real(8) is double, and only one of real(10) and real(16) is available, which corresponds to long double. This shouldn't be too hard to 

  -- math library: we need access to a library with quad variants, e.g. with a "__float128 sqrt(__float128 x)" function for square root, and so on; I already have implemented one such library relying on MPFR, but we need to keep our options open so people can link with other libraries in the future (I can imagine lifting some proper quad-fp library from glibc, even though it will be a pain to make standalone). See my post on the mpfr mailing-list for the code: http://websympa.loria.fr/wwsympa/arc/mpfr/2010-05/msg00008.html

  -- libgfortran I/O: this one sucks; we'll need a special function in the quad-support library that can output binary128. This can use MPFR too.


This goes for the technical part of the job... There is one more issue, which is how to best integrate this? Of course, this needs to be optional as it requires at least an MPFR target library in the current scheme. I see more than one option:
   1. assume that the user has compiled compile separately a quad-prec math library (says libmathq; possible relying on MPFR, as the implementation I propose) and arrange specs so that an option triggers linking to it
   2. assume that the user has an MPFR target library compiled, and include the quad math wrappers into libgfortran
   3. same as previous, but directly build mpfr (and gmp) for the target from in-tree sources

Option 3 seems unrealistic (putting too much burden on the GCC build system, which is already quite complicated as is). Option 2 has my preference, for now, but I welcome other opinions.


Regarding timing, if people think it's a nice thing to integrate and it makes sense, I expect I can have it fully working by the second half of July. I suppose this is OK regarding the GCC development cycle. A change such as this to the way intrinsics are handled (front-end change) would require heavy testing, of course, to be sure not to break anything.


I hope you will have many comments about this idea and my possible plans. Thanks in advance.

Regards,
FX