This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Clean up dbl-64 rint, nearbyint


On 03/12/12 17:45, Joseph S. Myers wrote:
> Richard, looking at other versions of these functions I'm suspicious
> of the alpha versions of nearbyint and nearbyintf (which just add and
> subtract 0x1p23 or 0x1p52 without checking the size of the argument).
> At least for normal IEEE arithmetic, that's not correct (for double,
> consider an argument of 0x1p52 + 1, for example, which is an integer
> but whose value will be changed when 0x1p52 is added and subtracted).
> If the alpha versions do indeed get such cases wrong I guess it's
> evidence we need more testcases for rint and nearbyint to cover these
> cases of large integer arguments.

Yes, that definitely looks wrong.  It should look pretty much exactly
like rint, with the range check first.

The thing about alpha is that you have to do special things to get
the inexact exception raised in the first place.  Normally we compile
with -mieee, but one needs -mieee-with-inexact in order to get that
exception raised.  Real hardware traps to the kernel emulator *every*
time it thinks inexact might be necessary.

Which reminds me, after I've been poking about with such things
recently: the fma implementations probably don't work as-is on
alpha, without a makefile change to enable inexact.  I've been
largely ignoring the alpha math errors recently, because that
almost certainly requires a bit of co-debugging with qemu...


r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]