From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14977 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: math/powf regression on d28cd0ad commit Date: Wed, 4 Dec 2019 10:33:06 +0100 Message-ID: <20191204093304.GH23985@port70.net> References: <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="142839"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: alankao@andestech.com To: musl@lists.openwall.com, Ruinland ChuanTzu Tsai Original-X-From: musl-return-14993-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 04 10:33:21 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 1icR29-000b1I-Ch for gllmg-musl@m.gmane.org; Wed, 04 Dec 2019 10:33:21 +0100 Original-Received: (qmail 7622 invoked by uid 550); 4 Dec 2019 09:33:18 -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 7601 invoked from network); 4 Dec 2019 09:33:17 -0000 Mail-Followup-To: musl@lists.openwall.com, Ruinland ChuanTzu Tsai , alankao@andestech.com Content-Disposition: inline In-Reply-To: <20191204021045.GA10870@APC301.andestech.com> Xref: news.gmane.org gmane.linux.lib.musl.general:14977 Archived-At: * Ruinland ChuanTzu Tsai [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.