From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15751 invoked by alias); 4 Apr 2002 20:57:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 15740 invoked from network); 4 Apr 2002 20:57:25 -0000 Received: from unknown (HELO taltos.codesourcery.com) (66.92.14.122) by sources.redhat.com with SMTP; 4 Apr 2002 20:57:25 -0000 Received: from zack by taltos.codesourcery.com with local (Exim 3.35 #1 (Debian)) id 16tEIO-0004Ia-00; Thu, 04 Apr 2002 12:57:24 -0800 Date: Thu, 04 Apr 2002 13:00:00 -0000 From: Zack Weinberg To: Robert Dewar Cc: gcc@gcc.gnu.org, java@gcc.gnu.org Subject: Re: Java floating-point mess Message-ID: <20020404205724.GB14253@codesourcery.com> References: <20020404115615.04DBBF28C0@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020404115615.04DBBF28C0@nile.gnat.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2002-04/txt/msg00169.txt.bz2 On Thu, Apr 04, 2002 at 06:56:15AM -0500, Robert Dewar wrote: > < 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