From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 89F913945052 for ; Tue, 13 Apr 2021 18:02:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 89F913945052 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: HJ/+dl7JnBGM+nPFIRrWPp1GA+KI5Mn2IPcB22XyATniQ1u+F5c1/udqo6l/CVzGZ84o7FF+UR NyOkWZzA3SZgG7qnfCZEft+jsuiUVpPsCOjOHy5n9pLrIcIBgad+1k45pRnx8lBP7dGwK9l0W7 e08peYfbEfhcH3gDzdFS9c8lAJx4jxoG/tCj37pAs7pKWrcvI4nJ0KRVixXz0LqlWR2c/CNaQ+ 1ASqqRSew/8OpwvW7oCznOB+fEx2t8q9f8OvlcbatftkTpiTbg12eCmxUjyjoKWG/kaYsbN+65 9QA= X-IronPort-AV: E=Sophos;i="5.82,219,1613462400"; d="scan'208";a="60101716" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 13 Apr 2021 10:02:13 -0800 IronPort-SDR: HnTFCJTxz4SivcNqgtePFE73yTzvtqcCA5vITq1uq+cb0sIq0IESrV9u/rT7V3vo4eU9NCzJhe 1vgqEFFfvzPQNwqVtmwX8OZ6LXpPGqXWVixuznNxGQS3Hod3Nt8WTFRC3OnsMceweZGh2lsKji NYQDCmuz2DJSzLU9n7a+KKsw3HNAtfDbvqVJTjSk2ZCwRwNo/EzRS0yIu7RrXxsFg2Nroj/3Pz k7024PwnV2EcgxMCsh8PBnfVeoJVCWgwtq95am9UZ3ytubXGlyJ++oqiPFGS1c+6GFsLisN0RY ++4= Date: Tue, 13 Apr 2021 18:02:07 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Adhemerval Zanella CC: Szabolcs Nagy , Vineet Gupta , "libc-alpha@sourceware.org" Subject: Re: [COMMITTED] arm: update libm test ulps In-Reply-To: <6fd7e855-3de3-3044-d56e-14ca1f0cd717@linaro.org> Message-ID: References: <20210408085827.5369-1-szabolcs.nagy@arm.com> <20210413095214.GV23289@arm.com> <6fd7e855-3de3-3044-d56e-14ca1f0cd717@linaro.org> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3122.1 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 18:02:15 -0000 On Tue, 13 Apr 2021, Adhemerval Zanella via Libc-alpha wrote: > The math/libm-test-support.c imposes maximum ulp limits depending of > the underling type: > > 228 if (testing_ibm128) > 229 /* The documented accuracy of IBM long double division is 3ulp > 230 (see libgcc/config/rs6000/ibm-ldouble-format), so do not > 231 require better accuracy for libm functions that are exactly > 232 defined for other formats. */ > 233 max_valid_error = exact ? 3 : 16; > 234 else > 235 max_valid_error = exact ? 0 : 9; > > And if I recall correctly there was a suggestion to consolidate and/or > remove the ulps file altogether and use the maximum valid error as the > threshold to report regressions. The only drawback I see of moving > towards it is each architecture won't see if some change has degraded > the function precision. And for some of the higher ulps values it might be good to improve the precision, which suggests having at least per-format if not per-architecture empirical bounds for each function. -- Joseph S. Myers joseph@codesourcery.com