Date: Sat, 23 Apr 2005 09:27:15 -0400 From: David Schultz <das@FreeBSD.ORG> To: Stefan Farfeleder <stefanf@FreeBSD.ORG> Cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/msun/src s_ceill.c s_floorl.c s_truncl.c Message-ID: <20050423132715.GA59057@VARK.MIT.EDU> In-Reply-To: <20050422084616.GB87979@wombat.fafoe.narf.at> References: <200504220830.j3M8UXSC030662@repoman.freebsd.org> <20050422084616.GB87979@wombat.fafoe.narf.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 22, 2005, Stefan Farfeleder wrote: > On Fri, Apr 22, 2005 at 08:30:33AM +0000, Stefan Farfeleder wrote: > > > Fix raising the inexact exception (FE_INEXACT) if the result differs from the > > argument. > > Unfortunately, _Qp_add fails to set the inexact exception on Sparc64; it > works with -mhard-quad-float though. Maybe it's time to set the inexact > exception via some MD assembler magic? Unlike i386, there's no way to explicitly raise FP exceptions on sparc64 except by executing arithmetic operations. (You can set FP exception flags, but that doesn't have the same side-effects as actually raising exceptions.) The feraiseexcept() implementation I wrote for sparc64 just does the following: volatile double d; [...] d = 0x1p-1022; d += 1.0; The correct MI way to raise exceptions when the right ones don't trigger naturally is feraiseexcept(). Eventually I mean to convert libm to do that where it currently uses arithmetic to generate exceptions. There are some catches, though, which is why I haven't done this already. It turns out that feraiseexcept() is far faster on i386 than generating exceptions via arithmetic, but it may be slower on other platforms. Also, unfortunately there are gcc optimizer bugs that still get in the way, especially on ia64. Therefore, for now it probably makes more sense to just be consistent with the rest of libm than use feraiseexcept(). As you point out, doing this doesn't quite work for quad precision. It turns out that libgcc is just broken with respect to FP exceptions. (John Hauser's SoftFloat library, which arm uses, is much better.) Since this is really a libgcc problem, there seems to be little point in fixing it for floor/ceil/trunc and leaving it broken everywhere else, so what you have is probably fine. > Please ignore my last message, I'll just use double addition to generate > the exception. Couldn't that result in a spurious underflow when logn double x gets converted to double precision? Consider x = 0x1p-2000L.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050423132715.GA59057>