This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, Fortran] Rework of floating point number reading
- From: "Janne Blomqvist" <blomqvist dot janne at gmail dot com>
- To: jvdelisle at verizon dot net
- Cc: "Daniel Kraft" <d at domob dot eu>, "Fortran List" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 30 Dec 2008 17:47:17 +0200
- Subject: Re: [Patch, Fortran] Rework of floating point number reading
- References: <1176455234.27818371230613970452.JavaMail.javamailuser@localhost>
On Tue, Dec 30, 2008 at 07:12, <jvdelisle@verizon.net> wrote:
> On the "powl (10.0, exponent)" question, I would be surprised if you could
> improve on it. It ought to be already doing things like lookup tables as
> part of the builtin.
IIRC when the exponent is an integer, builtin_powx() is expanded to
the powix functions in libgcc whose implementations look basically
like
double powi (double x, int n)
{
double y = n % 2 ? x : 1;
while (n >>= 1)
{
x = x * x;
if (n % 2)
y = y * x;
}
return y;
}
(we have the equivalent thing in the frontend as well for expanding it
inline when both base and exponent are constants)
One additional optimization that could be made here is that the base
is also an integer, and secondly to inline the function.
However, in light of Geert's comments perhaps the better way forward
would be to keep using strtod() and instead optimizing whatever we
must do before that, such as handling BZ/BN edit descriptors, changing
d/D exponent markers to e/E (which strtod doesn't understand, right?),
and so forth. And get rid of the sprintf() and pow() calls if
possible.
--
Janne Blomqvist