gcc 11.1.0: printf("%.43f\n", 0x1.52f8a8e32e982p-140): printed value is incorrectly rounded
Takashi Yano
takashi.yano@nifty.ne.jp
Sun Nov 28 12:38:39 GMT 2021
On Sun, 28 Nov 2021 16:43:11 +0900
Takashi Yano wrote:
> On Thu, 4 Nov 2021 13:24:42 +0100
> Corinna Vinschen wrote:
> > However, a much better fix would be to switch to gdtoa, as the BSDs and
> > Mingw64 do.
>
> I have tried to import gdtoa into newlib from OpenBSD.
>
> gdtoa seems to use malloc much, so it may not work in some of
> platforms due to insufficient heap. Therefore, new ldtoa.c tries
> gdtoa first and fallbacks to legacy ldtoa if gdtoa fails.
>
> To import gdtoa to newlib, I did:
> 1) Create "machine/ieee.h" which conditionally defines ieee_ext
> structure and EXT_TO_ARRAY32() macro depend on architecture.
> 2) Create arith.h which reflects endian of architecture.
> 3) Merge gdtoa.h with OpenBSD's gdtoa.h. __BEGIN_HIDDEN_DECLS,
> __END_HIDDEN_DECLS, PROTO_NORMAL() and DEF_STRONG() are
> defined as dummy in this header.
> 4) Replace malloc()/free() with _malloc_r()/_free_r().
> 5) Implement ACQUIRE_DTOA_LOCK() and FREE_DTOA_LOCK() macros
> using "sys/lock.h" for multi-threading environment.
> 6) Remove inclusion of "gd_qnan.h" which is not used.
>
> Please see attached patch for more details.
>
> I confirmed this works nicely with cygwin. Moreover, it is much
> faster than legacy ldtoa (more than 4 times faster).
>
> However, this may break some other supported platforms.
>
> Could anyone please check this?
Ah, in "machine/ieee.h", struct ieee_ext definition for
LDBL_MANT_DIG==64 and __IEEE_BIG_ENDIAN case, is obviously
wrong.
--
Takashi Yano <takashi.yano@nifty.ne.jp>
More information about the Newlib
mailing list