From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 256F83858D3C for ; Mon, 14 Nov 2022 21:55:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 256F83858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.96,164,1665475200"; d="scan'208";a="89844902" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 14 Nov 2022 13:55:34 -0800 IronPort-SDR: Cpkk1GHDV/+TCniKjZDRKXsp89bDayku5mT4MEHsidAF5++eB7xPuKcHFAHcH5+c+c2mWxKiOh PXzYVz3zTDPcJj/Ekds0t9Tm5bckyjj4KAuLPdxyyJlQS1c3CyrHFuZH/6WKjrpdB6Skz+H4Wp QHRy5wtG1LLezjwyKaJtr0rRcbAxKz4lHDxI7BsnJnZc6R5v1a2dOD/vGw/ImNREVWOOtmK3N1 KI1MgqCtr71ZZSkYEXTbnasYzllr0MwI+aiYKfBNR14zSYvned2NnMfHlG84QSpG8bXX1aJYzI q34= Date: Mon, 14 Nov 2022 21:55:29 +0000 From: Joseph Myers To: Jakub Jelinek CC: Aldy Hernandez , GCC patches , Andrew MacLeod Subject: Re: [PATCH] [range-ops] Implement sqrt. In-Reply-To: Message-ID: <6150f7fd-5a57-c138-f65e-8dc3bf13d11a@codesourcery.com> References: <20221113200553.440728-1-aldyh@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-08.mgc.mentorg.com (139.181.222.8) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3110.0 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sun, 13 Nov 2022, Jakub Jelinek via Gcc-patches wrote: > So, I wonder if we don't need to add a target hook where targets will be > able to provide upper bound on error for floating point functions for > different floating point modes and some way to signal unknown accuracy/can't > be trusted, in which case we would give up or return just the range for > VARYING. Note that the figures given in the glibc manual are purely empirical (largest errors observed for inputs in the glibc testsuite on a system that was then used to update the libm-test-ulps files); they don't constitute any kind of guarantee about either the current implementation or the API, nor are they formally verified, nor do they come from exhaustive testing (though worst cases from exhaustive testing for float may have been added to the glibc testsuite in some cases). (I think the only functions known to give huge errors for some inputs, outside of any IBM long double issues, are the Bessel functions and cpow functions. But even if other functions don't have huge errors, and some architecture-specific implementations might have issues, there are certainly some cases where errors can exceed the 9ulp threshold on what the libm tests will accept in libm-test-ulps files, which are thus considered glibc bugs. (That's 9ulp from the correctly rounded value, computed in ulp of that value. For IBM long double it's 16ulp instead, treating the format as having a fixed 106 bits of precision. Both figures are empirical ones chosen based on what bounds sufficed for most libm functions some years ago; ideally, with better implementations of some functions we could probably bring those numbers down.)) -- Joseph S. Myers joseph@codesourcery.com