This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Java floating-point mess
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Robert Dewar <dewar at gnat dot com>
- Cc: gcc at gcc dot gnu dot org, java at gcc dot gnu dot org
- Date: Thu, 4 Apr 2002 12:57:24 -0800
- Subject: Re: Java floating-point mess
- References: <20020404115615.04DBBF28C0@nile.gnat.com>
On Thu, Apr 04, 2002 at 06:56:15AM -0500, Robert Dewar wrote:
> <<The Java front end has a number of places that assume not only that
> the host and target floating point formats are identical, but that
> both are IEEE. I've tried to get rid of them, but run afoul of its
> not being possible to link real.o into gcjh -- it wants to drag in
> most of the back end.
> >>
>
> Presumably the complaint is about assuming that the host fpt format is
> IEEE, the target fpt format presumably MUST be IEEE, since this is required
> by Java, no?
Well, the Java front end doesn't appear to take any special care to
ensure that SFmode is IEEE single and DFmode double. (We'd have to
have a floating point emulator library built into libjava that
implemented IEEE fp, to get it right for non-IEEE targets.) But yes,
the code I'm looking at right now is only for the host side.
Thinking out loud... The major problem is with gjavah, which wants to
read in a .class file and print out things like
const jdouble pi = 3.1415926... ;
which are then going to be interpreted by the C++ compiler -- come to
think of it, there is no way to win here on a non-IEEE target.
Ignoring the language spec and using the target's floating point,
whatever it happens to be, might be the sanest thing to do from an
interoperability standpoint.
I think I can get around the immediate problem by using C99
hexadecimal floating-point constants.
[I should have cc:ed java@ from the beginning -- the original message
is at http://gcc.gnu.org/ml/gcc/2002-04/msg00135.html if anyone's
interested.]
zw