Porting libgcj...

[Tom Tromey]

>>>>> "Scott" == scottb  <scottb@netwinder.org> writes:

Scott> I think I have found the problem (at least for this case).  It
Scott> is the WORDS_TO_DOUBLE() macro in javaop.h.  The ARM has a
Scott> funny floating point memory layout for doubles.

Interesting.

Scott> This is fine to test the code, but not my idea of a decent
Scott> port.  There doesn't seem to be any other way of introducing
Scott> architecture dependent code into the tree however.  Does anyone
Scott> have any better suggestions?

If you can think of a way to test for this by compiling (and not
running) a test program, then we could do it in configure.in.  You
can't run a test program because of Canadian crosses.

I guess we could test for it at runtime, but that is fairly ugly.

Another way would be to add a new define and set it in the appropriate
branches of the large case in gcc's configure.in.  This is also ugly,
but probably a bit better since the host dependencies remain isolated
in configure.

I think we'll have to deal with this same problem in libjava.  We want
Double.doubltToLongBits to return consistent results on all platforms.
For libjava we definitely need an architecture test in configure.in,
since it is a target library.

Looking forward to the patch :-)

Tom