*math/powf regression on d28cd0ad commit@ 2019-12-04 2:10 Ruinland ChuanTzu Tsai2019-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

*2019-12-04 2:10 math/powf regression on d28cd0ad commit Ruinland ChuanTzu TsaiRe: math/powf regression on d28cd0ad commit@ 2019-12-04 9:33 ` Szabolcs Nagy0 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 indexThread 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