Hi Joseph, On Thu, Oct 29, 2020 at 10:05:38PM +0000, Joseph Myers wrote: > On Thu, 29 Oct 2020, Segher Boessenkool wrote: > > > 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? > > As far as I know, the code in libgcc for conversions *from* decimal *to* > binary (so the direction that uses strtof128 as opposed to the one using > strfrom128, in the binary128 case) works correctly, if the underlying libc > has accurate string/numeric conversion operations. > > Binary to decimal is another matter, even for cases such as float to > _Decimal64. I've just filed bug 97635 for that. > > Also note that if you want to use printf as opposed to strfromf128 for > IEEE binary128 you'll need to use __printfieee128 (the version that > expects long double to be IEEE binary128) which was introduced in glibc > 2.32, so that doesn't help with the glibc version dependencies.
libiberty has printf functions of its own, I was wondering if those work fine; if they do, that would solve all problems here. > When I investigated and reported several bugs in the conversion operations > in libdfp, I noted (e.g. https://github.com/libdfp/libdfp/issues/29 ) that > the libgcc versions were working correctly for those tests (and filed and > subsequently fixed one glibc strtod bug, missing inexact exceptions, that > I'd noticed while looking at such issues in libdfp). But the specific > case I tested for badly rounded conversions was the case of conversions > from decimal to binary, not the case of conversions from binary to > decimal, which, as noted above, turn out to be buggy in libgcc. Yeah :-( > Lots of bugs have been fixed in the glibc conversion code over the years > (more on the strtod side than in the code shared by printf and strfrom > functions). That code uses multiple-precision operations from GMP, which > avoids some complications but introduces others (it also needs to e.g. > deal with locale issues, which are irrelevant for libgcc conversions). Thanks for the info, Segher
