[Patch, Fortran] Rework of floating point number reading

Janne Blomqvist blomqvist.janne@gmail.com
Tue Dec 30 17:59:00 GMT 2008

On Tue, Dec 30, 2008 at 18:58, Daniel Kraft <d@domob.eu> wrote:
> Mikael Morin wrote:
>> Daniel Kraft wrote:
>>> Thomas Koenig wrote:
>>>> On Tue, 2008-12-30 at 09:37 +0100, Daniel Kraft wrote:
>>>>> 3.) Keep using strtod; I'm quite sure we can speed up the existing
>>>>> code still significantly by optimizing how the string passed to
>>>>> strtod is constructed.
>>>> What about using the glibc strtod as a base, and adjust it to Fortran?
>>>> The glibc copyright is already with the FSF, so I wouldn't expect legal
>>>> problems, but, of course, IANAL.
>>> Actually, I don't think this is a good idea, as (at least if strtod does
>>> really do some "magic" to get around the rounding problem as much as
>>> possible) this sounds like including possibly a lot of system-dependent,
>>> complicated code into libgfortran that does not really belong there.
>>> Just my opinion, though.
>> I think it is a good idea. If we keep the code as is, with a call to
>> strtod, we parse the string twice, the first time in libgfortran, and
>> the second time in strtod. Adding 'e' for example (for exponent) to a
>> strtod base won't add any complexity to the strtod code, so the speed
>> will be the same. However, supporting it without touching strtod adds a
>> lot of unnecessary code.
>> Just my opinion too ;-)
> That's true, but without having looked at glibc's strtod code, I fear it
> won't really be something clear and easy-to-read.  If we want a simple,
> clean and fast parsing routine, we could take my patch, including the
> possible rounding errors.  If we don't want to have them, I guess the way
> strtod does it must be something ugly and system-dependent (at least if
> strtod really does a lot better than my naive implementation).
> So I would not want to do our own parser (or copy the one from glibc for the
> matter) if we still wanted to care about precision more than my patch does.
>  But of course it may be worth a look at the actual glibc code; I'll try to
> do this now.

The actual implementation is here:


Looks quite scary! Based on nothing but the amount of code, I imagine
walking over the string once to convert the Fortran-specific stuff to
a format acceptable by strtod() won't have a huge performance impact,
especially considering the string is so short that there are no cache
effects to worry about. But, measurement beats idle speculation any

Janne Blomqvist

More information about the Gcc-patches mailing list