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

Takashi Yano <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
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 <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.