Date: Wed, 4 Dec 2019 10:10:45 +0800 From: Ruinland ChuanTzu Tsai <ruinland@...estech.com> To: <musl@...ts.openwall.com> CC: <alankao@...estech.com> Subject: math/powf regression on d28cd0ad commit 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.