From owner-freebsd-numerics@FreeBSD.ORG Sun Aug 12 23:01:53 2012 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75D41106564A for ; Sun, 12 Aug 2012 23:01:53 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id D6AAB8FC08 for ; Sun, 12 Aug 2012 23:01:52 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q7CN1qQC075591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 Aug 2012 09:01:52 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q7CN1kUZ021087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Aug 2012 09:01:46 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q7CN1kLL021085 for freebsd-numerics@freebsd.org; Mon, 13 Aug 2012 09:01:46 +1000 (EST) (envelope-from peter) Resent-From: Peter Jeremy Resent-Date: Mon, 13 Aug 2012 09:01:46 +1000 Resent-Message-ID: <20120812230146.GX20453@server.rulingia.com> Resent-To: freebsd-numerics@freebsd.org Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q6N4UK8u011309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 Jul 2012 14:30:21 +1000 (EST) (envelope-from brde@optusnet.com.au) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q6N4UKhd010905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Jul 2012 14:30:20 +1000 (EST) (envelope-from brde@optusnet.com.au) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6N4U1QB004152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2012 14:30:01 +1000 From: Bruce Evans Mail-Followup-To: freebsd-numerics@freebsd.org X-X-Sender: bde@besplex.bde.org To: Peter Jeremy In-Reply-To: <20120722220031.GA7791@server.rulingia.com> Message-ID: <20120723141319.P1189@besplex.bde.org> References: <5004A5C7.1040405@missouri.edu> <5004DEA9.1050001@missouri.edu> <20120717040118.GA86840@troutmask.apl.washington.edu> <20120717042125.GF66913@server.rulingia.com> <20120717043848.GB87001@troutmask.apl.washington.edu> <20120717225328.GA86902@server.rulingia.com> <20120717232740.GA95026@troutmask.apl.washington.edu> <20120718001337.GA87817@server.rulingia.com> <20120718123627.D1575@besplex.bde.org> <20120722121219.GC73662@server.rulingia.com> <20120722220031.GA7791@server.rulingia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sun, 12 Aug 2012 23:55:59 +0000 Cc: Diane Bruce , Bruce Evans , John Baldwin , David Chisnall , Stephen Montgomery-Smith , Bruce Evans , Steve Kargl , David Schultz , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 12 Aug 2012 23:01:53 -0000 X-Original-Date: Mon, 23 Jul 2012 14:30:01 +1000 (EST) X-List-Received-Date: Sun, 12 Aug 2012 23:01:53 -0000 On Mon, 23 Jul 2012, Peter Jeremy wrote: > On 2012-Jul-22 22:12:19 +1000, Peter Jeremy wrote: >> A have simplified the default (NaN + I*NaN) return from catanh() to >> the minimun to ensure that both real & imaginary parts return as NaN. >> I've been doing some experiments on mixing NaNs using x87, SSE, SPARC64 >> and ARM (last on Linux) and have come to the conclusion that there is >> no standard behaviour: Given x & y as NaNs, (x+y) can return either >> x or y, possibly with the sign bit from the other operand. depending >> on the FPU. > > I've tried running my exception test program on Solaris/SPARC using > SunStudio and it gives different results to FreeBSD/sparc64 in some > cases so it looks like the FreeBSD/sparc64 exception handling code > is also buggy. It is certainly MD, but I think it should be fixed within an arch. Not vary with CFLAGS depending on optimizations and which register set is selected, as happens on x86 due to the differences between x87 and SSE and the compiler's choice of the register set. For sparc64, 6 months ago before sparc64 switched from the old NetBSD(?)- contribed emulation to soft-float, the emulation was just broken, and I had to change parts of the library involving NaNs to get consistent behaviour (fortunately, the bugs seem to be all in user space). The behaviour varied with -mhard-quad-float. This option is not the default for sparc64 because no known sparc64 implementation implements it in hardware. The hardware only implements the opcodes, and traps to emulate them, while with soft-float the emulation uses similar code (but was more broken for NaNs) without traps. The traps just slow things down. I used -mhard-quad-float a bit anyway because it is easier to debug. In the disassembky it gives nice opcodes while soft-float gives large code for libcalls, and gdb makes a mess of both stepping over the libcalls if you don't want to see them (gdb steps into inline functions when you don't want this) and of displaying them when you do want to see them (display of register variables in inline functions is broken on most arches, and the envionment for the sparc64 libcall and trap code for emulation is especially challenging). > And, when the base gcc tries to shortcut floating point expressions > and execute them at compile time, it also gets exception handling > wrong in several cases (it'll correctly detect that a constant > expression evaluates to Inf or NaN but, in many cases, the NaN it > calculates is different to the x87 or SSE evaluation of the same > arguments). Possibly invalid optimizations, but I've had good results from evaluating 1.0/0 and 0.0/0 at compile time. gcc actually warns about these when I really want these to be evaluated without side effects (exceptions). Bruce