From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 2741 invoked from network); 22 Apr 2020 16:32:43 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 22 Apr 2020 16:32:43 -0000 Received: (qmail 18332 invoked by uid 550); 22 Apr 2020 16:32:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 18303 invoked from network); 22 Apr 2020 16:32:40 -0000 Date: Wed, 22 Apr 2020 12:32:28 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200422163228.GN11469@brightrain.aerifal.cx> References: <20200422161659.GM11469@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200422161659.GM11469@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Unexpected exceptions in math functions On Wed, Apr 22, 2020 at 12:16:59PM -0400, Rich Felker wrote: > On Wed, Apr 22, 2020 at 01:56:46PM +0000, leijitang wrote: > > Hi all, > > > > Recently we update musl in our project from 1.1.2 to version 1.2.0. But there are some errors about math functions when running > > the opensource test cases for musl, which are passed in musl 1.1.2. These errors are about exp2(), pow() and powf(). > > Logs are listed below. > > According to the commit message, the underflow exception is signaled if the result is in the subnormal range even if > > the result is exact (e.g. exp2(-1023.0)). But we got INEXACT exception at the same time, which is not as expected. > > Is this a problem? > > For practical purposes, probably not, because basically nothing uses > fenv, and clang doesn't even support it (its optimizer makes invalid > transformations that will break use of fenv). > > Strictly speaking, yes, and this should be fixed. exp2 with integer > argument should behave like scalbn/ldexp. > > > Otherwise, there is a overflow exception in powf(0x1.fffffep+127,0x1p+0) with FE_UPWARD rounding mode(log is also behind. As > > 0x1.fffffep+127 is the largest number that float can represent, there should not be INEXACT|OVERFLOW exceptions. > > I think that's correct. pow has various special cases that should be > exact, but catching them all to make sure they're exact is a bit of > work, and possibly hard to do without impacting the performance of > common cases. Still, use of pow in ways that should be exact is common > enough that I think this should be fixed. > > > If these are problems affirmed, is there any patch to fix this? > > Not yet. BTW Huawei folks, I've tried to CC you on replies but your mail system wrongly treats SPF-neutral/none as [hard]fail (rather than using it as one of many inputs into spam sorting heuristics). Getting that fixed would make it easier to participate in open source communities where lots of people don't have corporate-style mail setups restricting where mail can be sent from.