[-- Attachment #1: Type: text/plain, Size: 4795 bytes --] 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? 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. If these are problems affirmed, is there any patch to fix this? / $ ./exp2.exe src/math/special/exp2.h:12: bad fp exception: RN exp2(-0x1.ff8p+9)=0x1p-1023, want 0 got INEXACT|UNDERFLOW src/math/special/exp2.h:18: bad fp exception: RN exp2(-0x1.ff8p+9)=0x1p-1023, want 0 got INEXACT|UNDERFLOW src/math/special/exp2.h:20: bad fp exception: RN exp2(-0x1p+10)=0x1p-1024, want 0 got INEXACT|UNDERFLOW src/math/special/exp2.h:21: bad fp exception: RN exp2(-0x1.004p+10)=0x1p-1025, want 0 got INEXACT|UNDERFLOW src/math/special/exp2.h:22: bad fp exception: RN exp2(-0x1.0c8p+10)=0x1p-1074, want 0 got INEXACT|UNDERFLOW / $ ./pow.exe src/math/crlibm/pow.h:13: bad fp exception: RN pow(0x1p+1,-0x1.0c8p+10)=0x1p-1074, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:72: bad fp exception: RN pow(0x1p-1074,0x1p+0)=0x1p-1074, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:73: bad fp exception: RN pow(0x1p-1042,0x1p+0)=0x1p-1042, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:75: bad fp exception: RN pow(-0x1p-1074,0x1p+0)=-0x1p-1074, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:76: bad fp exception: RN pow(-0x1p-1042,0x1p+0)=-0x1p-1042, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:284: bad fp exception: RN pow(0x1p-1073,0x1p+0)=0x1p-1073, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:300: bad fp exception: RN pow(0x1p-1024,0x1p+0)=0x1p-1024, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:304: bad fp exception: RN pow(0x1p-1023,0x1p+0)=0x1p-1023, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:310: bad fp exception: RN pow(0x1.ffffffffffffcp-1023,0x1p+0)=0x1.ffffffffffffcp-1023, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:313: bad fp exception: RN pow(0x1.ffffffffffffep-1023,0x1p+0)=0x1.ffffffffffffep-1023, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:338: bad fp exception: RN pow(0x1p-537,0x1p+1)=0x1p-1074, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:437: bad fp exception: RN pow(0x1p+1,-0x1.0c8p+10)=0x1p-1074, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:498: bad fp exception: RN pow(0x1p+350,-0x1.8p+1)=0x1p-1050, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:499: bad fp exception: RN pow(0x1p+700,-0x1.8p+0)=0x1p-1050, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:516: bad fp exception: RN pow(0x1p+1023,-0x1p+0)=0x1p-1023, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:544: bad fp exception: RN pow(-0x1p-1073,0x1p+0)=-0x1p-1073, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:548: bad fp exception: RN pow(-0x1p-1024,0x1p+0)=-0x1p-1024, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:551: bad fp exception: RN pow(-0x1p-1023,0x1p+0)=-0x1p-1023, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:557: bad fp exception: RN pow(-0x1.ffffffffffffcp-1023,0x1p+0)=-0x1.ffffffffffffcp-1023, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:560: bad fp exception: RN pow(-0x1.ffffffffffffep-1023,0x1p+0)=-0x1.ffffffffffffep-1023, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:581: bad fp exception: RN pow(-0x1p-537,0x1p+1)=0x1p-1074, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:655: bad fp exception: RN pow(-0x1p+1,-0x1.0c8p+10)=0x1p-1074, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:695: bad fp exception: RN pow(-0x1p+350,-0x1.8p+1)=-0x1p-1050, want 0 got INEXACT|UNDERFLOW src/math/ucb/pow.h:708: bad fp exception: RN pow(-0x1p+1023,-0x1p+0)=-0x1p-1023, want 0 got INEXACT|UNDERFLOW / $ ./powf.exe src/math/ucb/powf.h:103: bad fp exception: RU powf(0x1.fffffep+127,0x1p+0)=0x1.fffffep+127, want 0 got INEXACT|OVERFLOW src/math/ucb/powf.h:530: bad fp exception: RN powf(0x1.fffff8p-127,0x1p+0)=0x1.fffff8p-127, want 0 got INEXACT|UNDERFLOW src/math/ucb/powf.h:533: bad fp exception: RN powf(0x1.fffffcp-127,0x1p+0)=0x1.fffffcp-127, want 0 got INEXACT|UNDERFLOW src/math/ucb/powf.h:719: bad fp exception: RN powf(-0x1.fffff8p-127,0x1p+0)=-0x1.fffff8p-127, want 0 got INEXACT|UNDERFLOW src/math/ucb/powf.h:722: bad fp exception: RN powf(-0x1.fffffcp-127,0x1p+0)=-0x1.fffffcp-127, want 0 got INEXACT|UNDERFLOW Regards [-- Attachment #2: Type: text/html, Size: 9190 bytes --]

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.

```
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.
```

* leijitang <leijitang@huawei.com> [2020-04-22 13:56:46 +0000]: > 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? underflow and inexact are always raised together. since this implementation is not correctly rounded it is expected that the result may have a tiny error, which can result such failure. we also don't guarantee correct inexact flag for math functions other than the correctly rounded ones. (note: spurious underflow is allowed by the standard, musl avoids it when the result is not in the subnormal range, but such exact subnormal cases may be wrong.) to fix this the special case handling code would need the original x and check if it's int when dealing with subnormal results. this is not out of question, but would increase register pressure to keep x around. > 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. > If these are problems affirmed, is there any patch to fix this? similar arugment can be made in this case: we return inf so overflow is right and our result is only incorrect by a tiny bit. on the other hand it would be nice to get obvious exact cases right. unfortunately this is not easy (the overflow problem can be fixed like above, in the special case handling, but normal range exact results may be off-by-one-ulp in non-nearest rounding mode and that's hard to fix without slowdown). i currently don't have a patch for these and i consider them QoI issues not critical bugs. > > > / $ ./exp2.exe > src/math/special/exp2.h:12: bad fp exception: RN exp2(-0x1.ff8p+9)=0x1p-1023, want 0 got INEXACT|UNDERFLOW > src/math/special/exp2.h:18: bad fp exception: RN exp2(-0x1.ff8p+9)=0x1p-1023, want 0 got INEXACT|UNDERFLOW > src/math/special/exp2.h:20: bad fp exception: RN exp2(-0x1p+10)=0x1p-1024, want 0 got INEXACT|UNDERFLOW > src/math/special/exp2.h:21: bad fp exception: RN exp2(-0x1.004p+10)=0x1p-1025, want 0 got INEXACT|UNDERFLOW > src/math/special/exp2.h:22: bad fp exception: RN exp2(-0x1.0c8p+10)=0x1p-1074, want 0 got INEXACT|UNDERFLOW > / $ ./pow.exe > src/math/crlibm/pow.h:13: bad fp exception: RN pow(0x1p+1,-0x1.0c8p+10)=0x1p-1074, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:72: bad fp exception: RN pow(0x1p-1074,0x1p+0)=0x1p-1074, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:73: bad fp exception: RN pow(0x1p-1042,0x1p+0)=0x1p-1042, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:75: bad fp exception: RN pow(-0x1p-1074,0x1p+0)=-0x1p-1074, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:76: bad fp exception: RN pow(-0x1p-1042,0x1p+0)=-0x1p-1042, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:284: bad fp exception: RN pow(0x1p-1073,0x1p+0)=0x1p-1073, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:300: bad fp exception: RN pow(0x1p-1024,0x1p+0)=0x1p-1024, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:304: bad fp exception: RN pow(0x1p-1023,0x1p+0)=0x1p-1023, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:310: bad fp exception: RN pow(0x1.ffffffffffffcp-1023,0x1p+0)=0x1.ffffffffffffcp-1023, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:313: bad fp exception: RN pow(0x1.ffffffffffffep-1023,0x1p+0)=0x1.ffffffffffffep-1023, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:338: bad fp exception: RN pow(0x1p-537,0x1p+1)=0x1p-1074, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:437: bad fp exception: RN pow(0x1p+1,-0x1.0c8p+10)=0x1p-1074, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:498: bad fp exception: RN pow(0x1p+350,-0x1.8p+1)=0x1p-1050, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:499: bad fp exception: RN pow(0x1p+700,-0x1.8p+0)=0x1p-1050, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:516: bad fp exception: RN pow(0x1p+1023,-0x1p+0)=0x1p-1023, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:544: bad fp exception: RN pow(-0x1p-1073,0x1p+0)=-0x1p-1073, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:548: bad fp exception: RN pow(-0x1p-1024,0x1p+0)=-0x1p-1024, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:551: bad fp exception: RN pow(-0x1p-1023,0x1p+0)=-0x1p-1023, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:557: bad fp exception: RN pow(-0x1.ffffffffffffcp-1023,0x1p+0)=-0x1.ffffffffffffcp-1023, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:560: bad fp exception: RN pow(-0x1.ffffffffffffep-1023,0x1p+0)=-0x1.ffffffffffffep-1023, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:581: bad fp exception: RN pow(-0x1p-537,0x1p+1)=0x1p-1074, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:655: bad fp exception: RN pow(-0x1p+1,-0x1.0c8p+10)=0x1p-1074, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:695: bad fp exception: RN pow(-0x1p+350,-0x1.8p+1)=-0x1p-1050, want 0 got INEXACT|UNDERFLOW > src/math/ucb/pow.h:708: bad fp exception: RN pow(-0x1p+1023,-0x1p+0)=-0x1p-1023, want 0 got INEXACT|UNDERFLOW > / $ ./powf.exe > src/math/ucb/powf.h:103: bad fp exception: RU powf(0x1.fffffep+127,0x1p+0)=0x1.fffffep+127, want 0 got INEXACT|OVERFLOW > src/math/ucb/powf.h:530: bad fp exception: RN powf(0x1.fffff8p-127,0x1p+0)=0x1.fffff8p-127, want 0 got INEXACT|UNDERFLOW > src/math/ucb/powf.h:533: bad fp exception: RN powf(0x1.fffffcp-127,0x1p+0)=0x1.fffffcp-127, want 0 got INEXACT|UNDERFLOW > src/math/ucb/powf.h:719: bad fp exception: RN powf(-0x1.fffff8p-127,0x1p+0)=-0x1.fffff8p-127, want 0 got INEXACT|UNDERFLOW > src/math/ucb/powf.h:722: bad fp exception: RN powf(-0x1.fffffcp-127,0x1p+0)=-0x1.fffffcp-127, want 0 got INEXACT|UNDERFLOW > > > Regards