From owner-freebsd-current@freebsd.org Thu Mar 14 20:11:50 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 5F726152AAA7; Thu, 14 Mar 2019 20:11:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A0E36A1BE; Thu, 14 Mar 2019 20:11:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2EKBgrC069294 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Mar 2019 22:11:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2EKBgrC069294 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2EKBgij069293; Thu, 14 Mar 2019 22:11:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Mar 2019 22:11:42 +0200 From: Konstantin Belousov To: John Baldwin Cc: Peter Jeremy , Steve Kargl , freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190314201142.GL2492@kib.kiev.ua> 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> <20190314192000.GI2492@kib.kiev.ua> <99ad567f-a1de-b3be-af4b-456df116bee7@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99ad567f-a1de-b3be-af4b-456df116bee7@FreeBSD.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home 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:11:50 -0000 On Thu, Mar 14, 2019 at 12:59:14PM -0700, John Baldwin wrote: > On 3/14/19 12:20 PM, Konstantin Belousov wrote: > > 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. > > At boot, a clean initial FPU state is stored in fpu_initialstate. > > Then on first FPU access from userspace (first for the given process > > context), this saved state is copied into hardware registers. The > > quirk is that for i386 binaries on amd64, we adjust fpu control word > > to what is expected by i386 binaries. > > > >> > >> 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. > > Changing default precision in crt1 would break the ABI. > > So what I don't understand then is what is gcc doing different than clang > in this case. I assume neither GCC _nor_ clang are adjusting the FPU in > compiler-generated code, and in fact as Steve's earlier tests shows, the > precision is set to PD by default when a clang-built binary is run. Precision control only affect elementary floating-point instructions. Could this be the cause ? SDM vol 1 8.1.5.2 Precision Control Field The precision-control bits only affect the results of the following floating-point instructions: FADD, FADDP, FIADD, FSUB, FSUBP, FISUB, FSUBR, FSUBRP, FISUBR, FMUL, FMULP, FIMUL, FDIV, FDIVP, FIDIV, FDIVR, FDIVRP, FIDIVR, and FSQRT.