bug-mes
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-mes] mes lib: dtoab


From: Jan Nieuwenhuizen
Subject: Re: [bug-mes] mes lib: dtoab
Date: Thu, 14 Mar 2019 23:32:33 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Danny Milosavljevic writes:

Hi Danny,

> the reason that dtoab doesn't work is an overflow in the long.  Did it
> work on i386?

No!  It says

--8<---------------cut here---------------start------------->8---
$ gcc-lib/lib/tests/mes/90-dtoab
1.-2147483648
-3.-2147483648
--8<---------------cut here---------------end--------------->8---

> IEEE 754 double precision has a 52 bit mantissa which means such a
> number would have 16 significant digits.  That cannot fit into long
> (10 significant digits), so the way dtoab is implemented is not
> correct.

Good catch!

> (It's not as bad as it could be since dtoab handles the fractional part and 
> the integral part separately)
>
> In any case, maybe it's enough for our purposes.
>
> The fix for ARM would be:
>
> --- a/lib/mes/dtoab.c
> +++ b/lib/mes/dtoab.c
> @@ -29,7 +29,11 @@ dtoab (double d, int base, int signed_p)
>    long i = (long) d;
>    char *p = ntoab (i, base, signed_p);
>    strcpy (dtoa_buf, p);
> +#if __arm__
> +  long f = (d - (double) i) * (double) 100000000;
> +#else
>    long f = (d - (double) i) * (double) 100000000000;
> +#endif
>    if (f)
>      {
>        if (f < 0)

That works better for x86, however the test still fails

--8<---------------cut here---------------start------------->8---
$ cat gcc-lib/lib/tests/mes/90-dtoab.log
--- ./../lib/tests/mes/90-dtoab.stdout  2019-02-08 19:34:45.871559352 +0100
+++ lib/tests/mes/90-dtoab.1    2019-03-14 23:23:14.990083591 +0100
@@ -1,2 +1,2 @@
-1.23
--3.14159265358
+1.22999999
+-3.14159265
XFAIL lib/tests/mes/90-dtoab.c (exit status: 1)
--8<---------------cut here---------------end--------------->8---

> If it was all right with you, we could just unconditionally make the
> precision even worse and just always use the shorter multiplicant :)

Yes, that's probably fine.  I think floats are only needed to build
gawk, but we run no gawk programs that use non-integer values.

> Otherwise we would have to have two different expected results in the
> tests and that's not nice.

> Furthermore, I don't understand how it worked on i386, if it did.
> Because sizeof(long) is 4 on i386 and 4 on arm.

Well, it doesn't work :-)

Sorry for that!
janneke

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | AvatarĀ® http://AvatarAcademy.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]