From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14976 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ruinland ChuanTzu Tsai Newsgroups: gmane.linux.lib.musl.general Subject: math/powf regression on d28cd0ad commit Date: Wed, 4 Dec 2019 10:10:45 +0800 Message-ID: <20191204021045.GA10870@APC301.andestech.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="248727"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.9.4 (2018-02-28) Cc: To: Original-X-From: musl-return-14992-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 04 03:11:09 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1icK8C-0012VT-Pa for gllmg-musl@m.gmane.org; Wed, 04 Dec 2019 03:11:08 +0100 Original-Received: (qmail 7931 invoked by uid 550); 4 Dec 2019 02:11:05 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7896 invoked from network); 4 Dec 2019 02:11:03 -0000 Content-Disposition: inline X-Originating-IP: [10.0.12.139] X-MAIL: ATCSQR.andestech.com xB42AjOq050427 Xref: news.gmane.org gmane.linux.lib.musl.general:14976 Archived-At: 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