Re: Classpath's doubleToLongBits
Andrew Haley <[email protected]> Thu, 21 Feb 2008 13:45:15 +0000
| Newsgroups | gmane.comp.java.classpath.devel,gmane.comp.java.vm.kaffe.general |
|---|---|
| Message-ID | <[email protected]> |
Dalibor Topic wrote: > Christian Thalinger schrieb: >> On Fri, 2008-02-08 at 12:25 +0100, Dalibor Topic wrote: >> >>> 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. >>> >> >> OK, I hope I still have access to this box, but I'll try to test them. >> > This one turned out to be a lot more fun to track down. > > It's pretty easy to rewrite the test whether to swap words in a > jdouble: put -0.0 into a jvalue's jdouble element, and if the > correspoding jlong bitstream is > 0, you have to swap the words. > It's a way of dynamically doing what the fdlibm #defines do, but it > works out the same way: swap on arm-debian-oabi. > > But that didn't fix the breakage. > > So I played around some more, and eventually, it turned out that > kaffe's classfile constant parser was working fine, and I was > reading in doubles the way arm's FPU expected them laid out, it > turned out the interpreter was working ok, too, and so on. > > But the breakage was still there. > > Turning the way, for example, the double constants were parsed > around, and doing it the 'wrong' way, fixed some regression tests, > but broke others. Similarly, reassembling doubles in the interpreter > from words the 'wrong' way had the same effect with other tests. > > So I had to examine things a bit more closely with jcf-dump. It > turned out that, since I was using a glibj.zip compiled on an > x86-linux host, the constant in the class java.lang.Double were laid > out correctly. But in the tests classes compiled on the > arm-oabi-linux platform using ecj on gcj-4.3, double constants were > laid out incorrectly, with their words swapped, as a comparison with > the tests compiled on x86-linux with ecj on gcj showed. Do we need a gcj fix somewhere? Andrew.