Date: Sun, 12 Aug 2012 23:01:53 -0000 From: Bruce Evans <brde@optusnet.com.au> To: Peter Jeremy <peter@rulingia.com> Cc: Diane Bruce <db@db.net>, Bruce Evans <brde@optusnet.com.au>, John Baldwin <jhb@freebsd.org>, David Chisnall <theraven@freebsd.org>, Stephen Montgomery-Smith <stephen@missouri.edu>, Bruce Evans <bde@freebsd.org>, Steve Kargl <sgk@troutmask.apl.washington.edu>, David Schultz <das@freebsd.org>, Warner Losh <imp@bsdimp.com> Subject: Re: Use of C99 extra long double math functions after r236148 Message-ID: <20120723141319.P1189@besplex.bde.org> Resent-Message-ID: <20120812230146.GX20453@server.rulingia.com> In-Reply-To: <20120722220031.GA7791@server.rulingia.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 23 Jul 2012, Peter Jeremy wrote: > On 2012-Jul-22 22:12:19 +1000, Peter Jeremy <peter@server.rulingia.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120723141319.P1189>