From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13075 invoked by alias); 22 Oct 2002 17:43:21 -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 13068 invoked from network); 22 Oct 2002 17:43:20 -0000 Received: from unknown (HELO mx2.redhat.com) (12.150.115.133) by sources.redhat.com with SMTP; 22 Oct 2002 17:43:20 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id g9MHgNP28645; Tue, 22 Oct 2002 13:42:23 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g9MHhJl21176; Tue, 22 Oct 2002 13:43:19 -0400 Received: from localhost.localdomain (frothingslosh.sfbay.redhat.com [172.16.24.27]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g9MHhID13917; Tue, 22 Oct 2002 10:43:18 -0700 Received: (from rth@localhost) by localhost.localdomain (8.11.6/8.11.6) id g9MHhH116406; Tue, 22 Oct 2002 10:43:17 -0700 X-Authentication-Warning: localhost.localdomain: rth set sender to rth@redhat.com using -f Date: Tue, 22 Oct 2002 11:49:00 -0000 From: Richard Henderson To: Robert Dewar Cc: aph@redhat.com, gcc@gcc.gnu.org Subject: Re: real.c implementation Message-ID: <20021022174317.GG16329@redhat.com> Mail-Followup-To: Richard Henderson , Robert Dewar , aph@redhat.com, gcc@gcc.gnu.org References: <20021022103809.BF06FF29F2@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021022103809.BF06FF29F2@nile.gnat.com> User-Agent: Mutt/1.4i X-SW-Source: 2002-10/txt/msg01353.txt.bz2 On Tue, Oct 22, 2002 at 06:38:09AM -0400, Robert Dewar wrote: > One thing I am not clear on for all ports is whether any of them trust > the assembler to do decimal to float conversion correctly. I know that > this was the case in GCC 2.8.1, and if you do that, the game gets lost > at the assembler level. It is definitely important to generate all > float constants in proper machine form in hex. The only place this happens is if the target allows fp constants as arguments to an instruction, e.g. on m68k. Which is probably going to fail if you try to put numbers like "+Inf" or whatnot there. One could consider that a port bug that it allows this. Otherwise, we do emit fp constants as integers. See assemble_real in varasm.c. r~