cvs commit: src/lib/msun/src s_ceill.c s_floorl.c s_truncl.c

David Schultz das at FreeBSD.ORG
Sat Apr 23 06:29:52 PDT 2005


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.


More information about the cvs-src mailing list