[kaffe] Re: Classpath's doubleToLongBits

[Christian Thalinger]

On Mon, 2008-02-18 at 04:03 +0100, Dalibor Topic wrote:
> 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.
> 
> So, current Kaffe CVS head interpreter works on arm-oabi-linux without 
> regressions. The regressions
> Kiyo-san has seen are caused by buggy compilers (jikes / ecj on gcj). 
> And I'll move on to comitting the
> jit patches for arm-linux next.

That sounds like it was a lot of work.  Did you change anything new in
GNU Classpath or should I test the current CVS version?

- twisti