From owner-freebsd-current@freebsd.org Thu Mar 14 20:08:18 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2DBD152A83D; Thu, 14 Mar 2019 20:08: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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 506B069CD7; Thu, 14 Mar 2019 20:08:17 +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.15.2/8.15.2) with ESMTPS id x2EK8FaL046252 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 Mar 2019 13:08:15 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x2EK8FOb046251; Thu, 14 Mar 2019 13:08:15 -0700 (PDT) (envelope-from sgk) Date: Thu, 14 Mar 2019 13:08:15 -0700 From: Steve Kargl To: Peter Jeremy Cc: John Baldwin , freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190314200815.GA46070@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <20190313164039.GA35340@troutmask.apl.washington.edu> <20190313212455.GA37717@troutmask.apl.washington.edu> <20190314063007.GA41995@troutmask.apl.washington.edu> <20190314185037.GI87064@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190314185037.GI87064@server.rulingia.com> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 506B069CD7 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 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: Thu, 14 Mar 2019 20:08:18 -0000 On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote: > On 2019-Mar-13 23:30:07 -0700, Steve Kargl wrote: > >AFAICT, all libm float routines need to be modified to conditional > >include ieeefp.h and call fpsetprec(FP_PD). This will work around > >issues is FP and libm. FreeBSD needs to issue an erratum about > >the numerical issues with clang. > > I vaguely recall looking into the x87 initialisation a long time ago > and STR that the startup code (either crtX or in the kernel) does > a fninit() to set the precision. I don't recall exactly where. > > IMO, calling fpsetprec() in every libm float function is overkill. It > should be enough to fpsetprec() before main() and add a note in the > man pages that libm is built to use the default FPU configuration and > changing the configuration (precision or rounding) may result in larger > errors. My understanding of the situation is that FreeBSD i386/387 sets the FPU to 53-bit precision (whether at start up or first access is immaterial). This was done long ago to prevent issues with different optimization levels leaving different intermediate results is registers with extended precision. You can observe the problem with the toy program I posted and clang. Compile it with -O0 and -O2. With the former you have max ULP of 2.9 (the desired result); with the latter you have a max ULP of 23.xxx. I have observed a 6 billion ULP issue when running my testsuite. As pointed out by John Baldwin, GCC is aware of the FPU setting. The problem with clang is that it seems to unconditionally assume the FPU is set to 64-bit precision. It is unclear if clang is generated the desired result for float routines in libm. The only to gaurantee the desired resut is to use fpsetprec(FP_PD), or fix clang to take into account the FPU environment. -- Steve