From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id 478D7383E83B for ; Mon, 30 Nov 2020 10:34:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 478D7383E83B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Paul.Zimmermann@inria.fr X-IronPort-AV: E=Sophos;i="5.78,381,1599516000"; d="scan'208";a="366044405" Received: from tomate.loria.fr (HELO tomate) ([152.81.10.51]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2020 11:34:58 +0100 Date: Mon, 30 Nov 2020 11:34:57 +0100 Message-Id: From: Paul Zimmermann To: Joseph Myers Cc: libc-alpha@sourceware.org In-Reply-To: (message from Joseph Myers on Fri, 27 Nov 2020 19:13:04 +0000) Subject: Re: [PATCH] add inputs to auto-libm-test-in yielding larger errors References: X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Mon, 30 Nov 2020 10:35:01 -0000 Dear Joseph, submitted as https://sourceware.org/bugzilla/show_bug.cgi?id=26982, and a similar one for tgamma (https://sourceware.org/bugzilla/show_bug.cgi?id=26983). Paul > Date: Fri, 27 Nov 2020 19:13:04 +0000 > From: Joseph Myers > CC: > User-Agent: Alpine 2.22 (DEB 394 2020-01-19) > > On Thu, 26 Nov 2020, Paul Zimmermann wrote: > > > thank you Joseph, I will commit that patch. > > > > I also found a case where lgamma() yields more than 10 ulps of error: > > > > Checking lgamma > > x=-0x1.f60c969a239f2p+1 d=1.0410549778851831e+01 > > > > This should be considered as a bug and entered into bugzilla? > > Any case where a libm function produces errors exceeding the maximum > accepted in ulps files (9 ulps for most formats, 16 for IBM long double), > in any rounding mode, measured in the way the libm testsuite does > (comparing against a correctly rounded result for that rounding mode, not > against an infinite-precision result) should be reported as a bug to > Bugzilla if there isn't already a bug open for inaccuracy of that > function. > > -- > Joseph S. Myers > joseph@codesourcery.com