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
