From owner-freebsd-toolchain@freebsd.org Thu Mar 14 21:03:20 2019 Return-Path: Delivered-To: freebsd-toolchain@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 3FD90152E0BF; Thu, 14 Mar 2019 21:03:20 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6A3C6CFDC; Thu, 14 Mar 2019 21:03:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 2219C15794; Thu, 14 Mar 2019 21:03:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Optimization bug with floating-point? To: sgk@troutmask.apl.washington.edu, Peter Jeremy Cc: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org 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> <20190314200815.GA46070@troutmask.apl.washington.edu> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <2987d041-a356-bd65-2157-4135d4f738ce@FreeBSD.org> Date: Thu, 14 Mar 2019 14:03:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <20190314200815.GA46070@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: D6A3C6CFDC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 21:03:20 -0000 On 3/14/19 1:08 PM, Steve Kargl 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. >> >> 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. OTOH, note that every other OS in 32-bit mode uses 64-bit precision, and amd64 also uses 64-bit precision by default IIUC. FreeBSD/i386 is definitely unique in this regard. Linux doesn't do it, none of the other BSD's do it (only Dragonfly does b/c they inherited it from FreeBSD). None of Solaris, Windows, etc. do it either if the gcc sources are to be trusted as a reference. That said, I think it must have to do with how clang vs GCC is handling saving the values in memory and whether or not it does truncation to 53 bits when stored in memory somehow. I was trying to poke around in GCC's sources to figure out if it was doing anything differently, but I couldn't find a difference in terms of function pointers, etc. The only difference is is the constants used in a set of structures. I haven't tried to track down what those struct member values control though. -- John Baldwin