Classpath's doubleToLongBits (was: Re: [kaffe] cross-compile error)

[Christian Thalinger]

On Fri, 2008-02-08 at 00:26 +0100, Dalibor Topic wrote:
> I've looked a bit closer at the 3 ARM OABI errors, in particular at the
> errors in test/regression/DoubleConst.java . That test fails because we 
> get the bitstreams of the doubles being tested when we call 
> Double.doubleToLongbits with swapped words, i.e. instead of 
> 0x7fefffffffffffff we get 0xffffffff7fefffff.
> 
> The current GNU Classpath implementation of 
> Java_java_lang_VMDouble_doubleToLongBits ends up swapping the words, 
> whenever __ARMEL__ is defined. That makes the DoubleConst test fail for 
> Cacao, Kaffe, etc. Since twisti said on IRC that he had spent a lot of 
> time trying to get it right on his ARM systems, I didn't want to mess 
> with the corresponding file in fdlibm.
> 
> So I wrote another implementation of the function, using ieee754.h (part 
> of glibc). Basically, it boils down to shifting the bits from the 
> bitfields to the right places inside the jlong. Easy.
> 
> Unfortunately, that didn't work on arm OABI debian sid either. It turned 
> out that glibc has a bug in the iee754.h header file, that comes to bite 
> one on arm OABI. Filed as
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464594 with a patch 
> attached.
> 
> Meanwhile, that still means that those 3 tests fail until glibc is 
> fixed. So ... I'll send in a couple of patches to the classpath patches 
> list to first rewrite the doubleToLongBits in Java (and the same for 
> Float), removing it from the VM interface, and then, I'll send in a 
> patch to add the ieee754.h way of dealing with fetching the bits to the 
> current way.
> 
> Does that sound useful?

That sounds actually very good, if it works on all configurations.  I
can remember we had a lot of problems to get these functions right on an
Arm system with VFP.  For more problems see also:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22800

- twisti