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
