From owner-freebsd-current@freebsd.org Wed Feb 10 01:42:17 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7E63A534E7C for ; Wed, 10 Feb 2021 01:42:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Db2Z12GqGz4hmk; Wed, 10 Feb 2021 01:42:16 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 11A1gE0X060492 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 9 Feb 2021 17:42:14 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 11A1gEt7060491; Tue, 9 Feb 2021 17:42:14 -0800 (PST) (envelope-from sgk) Date: Tue, 9 Feb 2021 17:42:14 -0800 From: Steve Kargl To: Dimitry Andric Cc: FreeBSD Current Subject: Re: [PACTH,libm] hypothl(x) mishandles subnormal numbers. Message-ID: <20210210014214.GA60428@troutmask.apl.washington.edu> References: <20210206203929.GA45801@troutmask.apl.washington.edu> <20210206210448.GC45801@troutmask.apl.washington.edu> <20210209231529.GA59891@troutmask.apl.washington.edu> <051767C6-85FB-48E8-AFE1-546DC41E8D17@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <051767C6-85FB-48E8-AFE1-546DC41E8D17@FreeBSD.org> X-Rspamd-Queue-Id: 4Db2Z12GqGz4hmk X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 01:42:17 -0000 On Wed, Feb 10, 2021 at 12:26:29AM +0100, Dimitry Andric wrote: > > > On 10 Feb 2021, at 00:15, Steve Kargl wrote: > > > > This patch fixes the issue. t1 is used to scale the subnormal > > numbers. It is generated by scaling the exponent, but that > > only works if t1 is 1 not 0. > > > > Index: src/e_hypotl.c > > =================================================================== > > --- src/e_hypotl.c (revision 2342) > > +++ src/e_hypotl.c (working copy) > > @@ -82,7 +82,7 @@ hypotl(long double x, long double y) > > man_t manh, manl; > > GET_LDBL_MAN(manh,manl,b); > > if((manh|manl)==0) return a; > > - t1=0; > > + t1=1; > > SET_HIGH_WORD(t1,ESW(MAX_EXP-2)); /* t1=2^(MAX_EXP-2) */ > > b *= t1; > > a *= t1; > > > > Ah, having looked at the glibc code, I had concluded something similar > in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253313#c2, but > using INSERT_LDBL80_WORDS(t1,ESW(MAX_EXP-2),0x8000000000000000). > > Your solution is a lot simpler though. :) Note that to make it work, I > also needed to insert a volatile into the INSERT_LDBL80_WORDS() macro. I don't look at glibc's libm code due to possible Copyright issues (long/short story that I rather not get into here). I do, however, have a math_sgk.h that appears at the end of math_privated.h with a bunch of instrumentation code hidden behind -DEBUG. For the above, it becomes t1=0; SET_HIGH_WORD(t1,ESW(MAX_EXP-2)); /* t1=2^(MAX_EXP-2) */ PRNL(t1); which yields inf as output. Clearly, not a scaling of a subnormal to a normal number. > There are more places where this is apparently needed, due to the way > recent clang versions tend to over-optimize floating point code at > compile time. And specifically for the case where one union field is > written, and then another field read, sometimes leading to unexpected > results... Hmmm. This is a bummer. I suppose someone will say the code in msun is using undefined behavior or some such standardese. -- Steve