From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C34DD3857B84; Mon, 13 Jun 2022 17:59:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C34DD3857B84 From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libquadmath/105101] incorrect rounding for sqrtq Date: Mon, 13 Jun 2022 17:59:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libquadmath X-Bugzilla-Version: unknown X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: joseph at codesourcery dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2022 17:59:52 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105101 --- Comment #20 from 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, ma= pped > to the same library routines with significant difference that _Float128 i= s 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. >=20 > 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 > sqrtf128(). > Unfortunately, nothing like that appears to be present in either math.h o= r in > library. Am I doing something wrong? The function should be sqrtf128 (present in glibc 2.26 and later on=20 x86_64, x86, powerpc64le, ia64). I don't know about support in non-glibc=20 C libraries. > Right now, there are only two [gcc] platforms with hw binary128 - IBM POW= ER and > IBM z. I am not sure about the later, but the former has xssqrtqp instruc= tion > 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 correc= tly=20 > > rounding, in all rounding modes, and correct rounding implies correct=20 > > exceptions, *and* correct exceptions for fma includes getting right the= =20 > > architecture-specific choice of whether tininess is detected before or= =20 > > after rounding. >=20 > 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=20 tininess detection rules (to quote IEEE 754, "The implementer shall choose= =20 how tininess is detected [i.e. from the two options listed immediately=20 above this quote in IEEE 754], but shall detect tininess in the same way=20 for all operations in radix two"), which doesn't apply to sqrt because=20 sqrt results can never underflow. (I expect the existing soft-fp version of fma in glibc to be rather better= =20 optimized than the soft-fp version of sqrt.) > I don't quite or understand why you say that. First, I don't remember usi= ng any > double math in the variant of sqrtq() posted here. So, may be, you meant > division? > Here I use doable math, but IMO, I use it in a way that never causes > exceptions. Yes, the double division. If that division can ever be inexact when the=20 result of the square root itself is exact, you have a problem (which in=20 turn could lead to actual incorrectly rounded results from other functions= =20 such as the square root operations rounding to a narrower type, when the=20 round-to-odd versions of those functions are used, because the=20 round-to-odd technique relies on correct "inexact" exceptions).=