Re: Classpath's doubleToLongBits
Dalibor Topic <[email protected]> Fri, 08 Feb 2008 12:25:48 +0100
| Newsgroups | gmane.comp.java.classpath.devel,gmane.comp.java.vm.kaffe.general |
|---|---|
| Message-ID | <[email protected]> |
Christian Thalinger schrieb: > 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 > Yeah, that's why I'd like to go step by step, and first slash the VM interface methods I can slash, and then implement it with ieee754.h as an option, (adding a #define BIG_ENDIAN __BIG_ENDIAN for the broken glibc versions). I'll make sure to post the native patches for comments first, as I don't have access to a VFP box. cheers, dalibor topic