mailing list of musl libc
 help / color / Atom feed
* math/powf regression on d28cd0ad commit
@ 2019-12-04  2:10 Ruinland ChuanTzu Tsai
  2019-12-04  9:33 ` Szabolcs Nagy
  0 siblings, 1 reply; 2+ messages in thread
From: Ruinland ChuanTzu Tsai @ 2019-12-04  2:10 UTC (permalink / raw)
  To: musl; +Cc: alankao

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 ? )

Best regards,
Ruinland


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: math/powf regression on d28cd0ad commit
  2019-12-04  2:10 math/powf regression on d28cd0ad commit Ruinland ChuanTzu Tsai
@ 2019-12-04  9:33 ` Szabolcs Nagy
  0 siblings, 0 replies; 2+ messages in thread
From: Szabolcs Nagy @ 2019-12-04  9:33 UTC (permalink / raw)
  To: musl, Ruinland ChuanTzu Tsai; +Cc: alankao

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-04  2:10 math/powf regression on d28cd0ad commit Ruinland ChuanTzu Tsai
2019-12-04  9:33 ` Szabolcs Nagy

mailing list of musl libc

Archives are clonable: git clone --mirror http://inbox.vuxu.org/musl

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git