From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20799 invoked by alias); 9 Mar 2007 18:33:55 -0000 Received: (qmail 20789 invoked by uid 22791); 9 Mar 2007 18:33:54 -0000 X-Spam-Check-By: sourceware.org Received: from dessent.net (HELO dessent.net) (69.60.119.225) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 Mar 2007 18:33:47 +0000 Received: from localhost ([127.0.0.1] helo=dessent.net) by dessent.net with esmtp (Exim 4.50) id 1HPjuO-0006yd-8r; Fri, 09 Mar 2007 18:33:40 +0000 Message-ID: <45F1A884.B239ACBC@dessent.net> Date: Fri, 09 Mar 2007 18:47:00 -0000 From: Brian Dessent Reply-To: gcc-help@gcc.gnu.org X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: Terry Frankcombe CC: gcc-help@gcc.gnu.org Subject: Re: Internal representation of double variables - 3.4.6 vs 4.1.0 References: <1173463194.5215.5.camel@fkpc167> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2007-03/txt/msg00134.txt.bz2 Terry Frankcombe wrote: > After reading this, I went off looking for a gcc option enforcing IEEE > floating point behaviour, assuming gcc was like the Intel compilers and > by default sacrificed some exactness in the floating point model for > speed, even with no optimisation. I could find none. So, does gcc use > a well-defined and reproducible floating-point model by default? If > not, can one turn on strict IEEE arithmetic? That is not the problem. The problem is that the intel x86 processor uses an internal 80 bit representation for 'double', which normally has only 64 bits. This causes excess precision, which can appear as rounding errors in the ULP, but are not really errors, just misunderstandings of how IEE 754 works. You can work around this with -ffloat-store but this incurs a speed penalty as it means temporary values can't be kept in registers but repeatedly stored and loaded from memory. Or you can use SSE for fp math (-mfpmath=sse) instead of 387, if your architecture supports it. See gcc bug 323 for examples of this non-bug being reported over and over again dozens of times over the years. Brian