[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Partial Double/Float merge with libgcj

From: Chris Gray
Subject: Re: Partial Double/Float merge with libgcj
Date: Wed, 17 Oct 2001 14:38:33 +0200

Tom Tromey wrote:

> >>>>> "Chris" == Chris Gray <address@hidden> writes:
> Chris> An interesting twist on this: jikes seems to have its own idea
> Chris> of the correct bit-pattern for NaN (0xffc00000 instead of
> Chris> 0x7fc0000).  This shouldn't matter if all NaN's are
> Chris> canonicalized to the same value.
> My understanding is that floatToIntBits is required to return
> 0x7fc00000 for any NaN, and that Float.NaN must be the same as
> Float.intBitsToFloat(0x7fc00000).
> This doesn't necessarily imply that there is a Jikes bug though.

No.  It just means that Float.floatToRawIntBits(Float.NaN) returns
0xffc00000 when you might naively have expected 0x7fc00000.

> It depends on exactly when Jikes uses that particular value.
> Float.floatToRawIntBits can return other NaN values, and presumably
> the VM could use them as well.  For instace libgcj uses whatever
> the underlying hardware decides, and only does the canonicalization
> when the real bit pattern might be seen by Java.
> Tom
> _______________________________________________
> Classpath mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]