Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 4 Dec 2019 10:10:45 +0800
From: Ruinland ChuanTzu Tsai <>
To: <>
CC: <>
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,

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.