On Thu, Oct 29, 2020 at 06:31:54PM +0000, Joseph Myers wrote: > On Thu, 29 Oct 2020, Segher Boessenkool wrote: > > 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.)
And we otherwise support at least glibc 2.17 still (that is what RHEL 7 has). > 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). Does the printf code in libgcc handle things correctly for IEEE QP float as long double, do you know? Segher
