[Bug libquadmath/105101] incorrect rounding for sqrtq
joseph at codesourcery dot com
Mon Jun 13 17:59:52 GMT 2022
--- Comment #20 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sat, 11 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:
> On MSYS2 _Float128 and __float128 appears to be mostly the same thing, mapped
> to the same library routines with significant difference that _Float128 is not
> accessible from C++. Since all my test benches are written in C++ I can't even
> validate that what I wrote above is 100% true.
> Also according to my understanding of glibc docs (not the clearest piece of
> text that I ever read) a relevant square root routine should be named
> Unfortunately, nothing like that appears to be present in either math.h or in
> library. Am I doing something wrong?
The function should be sqrtf128 (present in glibc 2.26 and later on
x86_64, x86, powerpc64le, ia64). I don't know about support in non-glibc
> Right now, there are only two [gcc] platforms with hw binary128 - IBM POWER and
> IBM z. I am not sure about the later, but the former has xssqrtqp instruction
> which is likely the right way to do sqrtq()/sqrtf128() on this platform. If z
> is the same, which sound likely, then implementation based on binary128
> mul/add/fma by now has no use cases at all.
That may well be the case for sqrt.
> > fma is a particularly tricky case because it *is* required to be correctly
> > rounding, in all rounding modes, and correct rounding implies correct
> > exceptions, *and* correct exceptions for fma includes getting right the
> > architecture-specific choice of whether tininess is detected before or
> > after rounding.
> I suspect that by strict IEEE-754 rules sqrt() is the same as fma(), i.e. you
> have to calculate a root to infinite precision and then to round with
> accordance to current mode.
Yes, but fma has the extra complication of the architecture-specific
tininess detection rules (to quote IEEE 754, "The implementer shall choose
how tininess is detected [i.e. from the two options listed immediately
above this quote in IEEE 754], but shall detect tininess in the same way
for all operations in radix two"), which doesn't apply to sqrt because
sqrt results can never underflow.
(I expect the existing soft-fp version of fma in glibc to be rather better
optimized than the soft-fp version of sqrt.)
> I don't quite or understand why you say that. First, I don't remember using any
> double math in the variant of sqrtq() posted here. So, may be, you meant
> Here I use doable math, but IMO, I use it in a way that never causes
Yes, the double division. If that division can ever be inexact when the
result of the square root itself is exact, you have a problem (which in
turn could lead to actual incorrectly rounded results from other functions
such as the square root operations rounding to a narrower type, when the
round-to-odd versions of those functions are used, because the
round-to-odd technique relies on correct "inexact" exceptions).
More information about the Gcc-bugs