On Thu, 29 Oct 2020, Segher Boessenkool wrote: > Hi! > > On Thu, Oct 29, 2020 at 12:45:15PM -0400, Michael Meissner wrote: > > On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote: > > > > +#if HAVE_KF_MODE > > > > + strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x); > > > > +#else > > > > sprintf (buf, BFP_FMT, (BFP_VIA_TYPE) x); > > > > +#endif > > > > > > Does strfromf128 exist everywhere we build this? It isn't a standard > > > function. > > > > Yes, it is in ISO/IEC TS 18661-3, which is the document that describes most > > of > > the *f128 functions. > > But this means it does *not* exist most places we build this? Not the > whole world is Linux (and even then, it is probably a too recent > addition).
strfromf128 and strtof128 were added for powerpc64le-linux-gnu in glibc 2.26. (The variants that are namespace-clean in the absence of 18661-3, which may be relevant when being used for long double, __strfromieee128 and __strtoieee128, were added in 2.32.) Doing these conversions accurately is nontrivial. Converting via strings is the simple approach (i.e. the one that moves the complexity somewhere else). There are more complicated but more efficient approaches that can achieve correct conversions with smaller bounds on resource usage (and there are various papers published in this area), but those involve a lot more code (and precomputed data, with a speed/space trade-off in how much you precompute; the BID code in libgcc has several MB of precomputed data for that purpose). -- Joseph S. Myers jos...@codesourcery.com
