From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11168 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] fix underflow exception in fma and fmal Date: Sun, 19 Mar 2017 15:39:53 +0100 Message-ID: <20170319143953.GQ2082@port70.net> References: <20170319033613.GO2082@port70.net> <20170319141249.GR1693@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1489934407 17839 195.159.176.226 (19 Mar 2017 14:40:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 19 Mar 2017 14:40:07 +0000 (UTC) User-Agent: Mutt/1.6.0 (2016-04-01) To: musl@lists.openwall.com Original-X-From: musl-return-11183-gllmg-musl=m.gmane.org@lists.openwall.com Sun Mar 19 15:40:03 2017 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.84_2) (envelope-from ) id 1cpc00-00042t-Qn for gllmg-musl@m.gmane.org; Sun, 19 Mar 2017 15:40:00 +0100 Original-Received: (qmail 19518 invoked by uid 550); 19 Mar 2017 14:40: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 19500 invoked from network); 19 Mar 2017 14:40:04 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20170319141249.GR1693@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:11168 Archived-At: * Rich Felker [2017-03-19 10:12:49 -0400]: > On Sun, Mar 19, 2017 at 04:36:14AM +0100, Szabolcs Nagy wrote: > > another corner case in the freebsd fma code where signaling underflow > > may be missed for an inexact subnormal result. > > (fmaf and x86 fma are not affected) > > --- > > src/math/fma.c | 7 +++++++ > > src/math/fmal.c | 8 ++++++++ > > 2 files changed, 15 insertions(+) > > > > diff --git a/src/math/fma.c b/src/math/fma.c > > index 741ccd75..c69918d1 100644 > > --- a/src/math/fma.c > > +++ b/src/math/fma.c > > @@ -279,6 +279,13 @@ static inline double add_and_denormalize(double a, double b, int scale) > > uhi.i += 1 - (((uhi.i ^ ulo.i) >> 62) & 2); > > sum.hi = uhi.f; > > } > > +#ifdef FE_UNDERFLOW > > + /* > > + * Raise underflow manually because scalbn won't do it if all > > + * lost bits are 0: fma(-0x1p-1000, 0x1.000001p-74, 0x1p-1022) > > + */ > > + feraiseexcept(FE_UNDERFLOW); > > +#endif > > Can you explain why it should happen if all lost bits are zero > (usually that's an exact case). I imagine it's something specific to > fma or its implementation but it's not obvious to me. > this case is for nearest rounding mode when the result is in the subnormal range, at this point the result is represented as hi,lo,scale but the final returned value is computed as scalbn(hi,scale) (the last bits of hi are adjusted if required for correct rounding), however scalbn fails to raise underflow if lo!=0 and all lost bits of hi are 0. the example is such a case: 0x1p-1022 - 0x1.000001p-1074 then hi=1-eps,lo=-0x1p-76,scale=-1022 or maybe with shifted scale and exponents, but in the end only one bit is lost from hi which is zero, alternatively i could do scalbn(lo,scale) too to raise underflow.