gcc 11.1.0: printf("%.43f\n", 0x1.52f8a8e32e982p-140): printed value is incorrectly rounded

[Takashi Yano]

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?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ldtoa-Import-gdtoa-from-OpenBSD.patch
Type: application/octet-stream
Size: 108421 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20211128/5bfde85b/attachment-0001.obj>