This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch, libgfortran] Towards __float128 support
- From: FX <fxcoudert at gmail dot com>
- To: Tobias Burnus <tobias dot burnus at physik dot fu-berlin dot de>
- Cc: gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org
- Date: Fri, 27 Aug 2010 20:06:59 +0200
- Subject: Re: [patch, libgfortran] Towards __float128 support
- References: <20100827155415.GA11965@physik.fu-berlin.de>
Hi Tobias,
> - x2rev = 2.0F/x;
> + x2rev = 2/x;
>
> I am not really a really happy with that change even though
> there should be no conversion problem in this case.
I guessed, as you're the original author, that you would prefer it with the suffix :)
As you said, there's no conversion problem: 0, 1 and 2 are perfectly representable in whatever float format we're using.
> Why can't you simply continue to use 2.0f, 2.0, 2.0l -- and
> use 2.0q for __float128?
Just because it's more work, and not really needed right now. Because, for the kind=16 version, we need to define a macro inside #if/#else#endif, just as I did for MATHFUNC. Which is already an ugly and long macro, so I'd rather not add a second one.
But it turns out there's a possibility, which I introduced some time ago: the GFC_REAL_*_LITERAL macros. Which gives the attached patch:
(for m4)
- x2rev = 2.0'Q`/x;
+ x2rev = GFC_REAL_'rtype_kind`_LITERAL(2)/x;
(for generated kind=16)
- x2rev = 2.0L/x;
+ x2rev = GFC_REAL_16_LITERAL(2)/x;
Would that be acceptable to you? Do you also want the 0 and 1 floating-point values to be converted back the same way?
FX