Re: math/powf regression on d28cd0ad commit

[Szabolcs Nagy <nsz@port70.net>]

* Ruinland ChuanTzu Tsai <ruinland@andestech.com> [2019-12-04 10:10:45 +0800]:
> Hi musl fellows,
> sorry for making the noise again.
> 
> Yet I encountered a regression of libc-test's math/powf on x86_64 and
> RV64 during the transitions from v1.1.22 to v1.1.23. After bisecting, I
> managed to locate the commit that breaks powf() test to be d28cd0ad ,
> which introduces a new implementation of powf().
> 
> Fail log is shown as follow :
> 
> src/math/ucb/powf.h:103: bad fp exception: RU powf(0x1.fffffep+127,0x1p+0)=0x1.fffffep+127, want 0 got INEXACT|OVERFLOW 
> X src/math/ucb/powf.h:530: bad fp exception: RN powf(0x1.fffff8p-127,0x1p+0)=0x1.fffff8p-127, want 0 got INEXACT|UNDERFLOW
> X src/math/ucb/powf.h:533: bad fp exception: RN powf(0x1.fffffcp-127,0x1p+0)=0x1.fffffcp-127, want 0 got INEXACT|UNDERFLOW
> X src/math/ucb/powf.h:719: bad fp exception: RN powf(-0x1.fffff8p-127,0x1p+0)=-0x1.fffff8p-127, want 0 got INEXACT|UNDERFLOW
> X src/math/ucb/powf.h:722: bad fp exception: RN powf(-0x1.fffffcp-127,0x1p+0)=-0x1.fffffcp-127, want 0 got INEXACT|UNDERFLOW
> FAIL ./src/math/powf.exe [status 1]
> 
> I took a quick investigation on the RU powf(0x1.fffffep+127,0x1p+0).
> In the very end of powf() , a "y", which is a little bit larger than the
> expected outcome, gets passed to eval_as_float(). Since we're rounding-
> up, it will become an INF, causing the testcase to fail.
> 
> It makes me wonder whether the old implementation is safe enough for
> someone to revert this change by her/his own ? ( I reverted the change
> for testing. It seems to be side-effect free ? )

i don't think it's a good idea to revert to old powf.

there are issues around overflow and underflow in *non-nearest*
rounding modes. i may try to fix that, but it's low priority.

other libcs are completely broken in such modes, so you won't
find any software that depends on math library behaviour in
non-default rounding. (e.g. in musl sin/cos/tan has huge errors
in non-nearest rounding, so we have no guarantees), worse than
that: most compilers/language implementations don't support
non-nearest rounding at all (all languages other than c and
fortran and most optimizing c implementations like llvm don't
support non-default rounding at all, gcc -frounding-math is
an exception)

other libcs don't guarantee the behaviour on exact underflow
either: raising undeflow spuriously is acceptable then.

glibc uses the same powf, android uses the same powf.

if you find actual real world cases where this matters then
let me know.

the tests are there so we can test corner-case behaviour.