Re: Partial Double/Float merge with libgcj

[Chris Gray]

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
> http://mail.gnu.org/mailman/listinfo/classpath