On Tue, 30 Nov 2021 16:09:26 +0100 Corinna Vinschen wrote: > On Nov 30 19:51, Takashi Yano wrote: > > On Mon, 29 Nov 2021 16:55:32 +0100 > > Corinna Vinschen wrote: > > > On Nov 29 23:24, Takashi Yano wrote: > > > > [...] > > > > > > > > I have tried to import gdtoa into newlib from OpenBSD. > > > > > > > > [...] > > > [...struct __reent stuff...] > > Thanks for checking and advice. I have done these. > > > > > As for the allocations, how big are those? If they are comparable with > > > the allocation we now perform in _ldtoa_r, it might not be worth to keep > > > both functions. Some users of smaller targets might also complain that > > > > I saw max 16404 byte malloc(). > > > > > using printf now always pulls in both variants of ldtoa, thus raising > > > code size unnecessarily. It might be better to keep the calls separate > > > and only use one or the other, per target or per code size constraints, > > > perhaps as a configure option. > > > > I have added --enable-newlib-use-gdtoa option, which defaults > > to 'yes', into newlib/configure.ac. Is this the right thing? > > That patch looks good to me, at least as far as Cygwin is concerned. Thanks for reviewing. > This isn't essential, but it might make sense to rename __ldtoa to > _ldtoa_r to avoid an extra function call, which could be time consuming > and add stack pressure. I. e., in gdtoa-ldtoa.c > > #ifdef _USE_GDTOA > // all code in gdtoa-ldtoa.c > #endif > > and in ldtoa.c: > > #ifndef _USE_GDTOA > // all code in ldtoa.c > #endif > > AFAICS, __ldtoa could easily be changed to take the long double argument > by value because it's used in only two places, one of which just checks > the value anyway. But, as I said, not essential. We can keep in mind > for the time being. Done. > Could some people with other targets than Cygwin give this patch a try? > RTEMS, anybody? I would appreciate it. -- Takashi Yano