From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28752 invoked by alias); 3 Jun 2002 13:36:08 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 28737 invoked by uid 71); 3 Jun 2002 13:36:06 -0000 Date: Mon, 03 Jun 2002 06:36:00 -0000 Message-ID: <20020603133606.28728.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Tim Prince Subject: Re: c++/6914: -O2 and -O give different results for the same valid FP code Reply-To: Tim Prince X-SW-Source: 2002-06/txt/msg00067.txt.bz2 List-Id: The following reply was made to PR c++/6914; it has been noted by GNATS. From: Tim Prince To: veksler@il.ibm.com, gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org Cc: Subject: Re: c++/6914: -O2 and -O give different results for the same valid FP code Date: Mon, 3 Jun 2002 06:30:53 -0700 On Monday 03 June 2002 06:09, Michael Veksler wrote: > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc& >pr=6914 > > So here are my conclusions (after reading the assembly, and running gdb > on it): > Floating point on x86 is done on 80 bit registers (IEEE's double > extended type). > GCC generates code to exploit all 80 bits during divide. It then spills > the result > to memory. > > The second divide is not spilled to memory, and the comparison is done > between truncated value (which lost accuracy), and a completely accurate > 80 bit > value. > According to http://www.validlab.com/goldberg/paper.ps this does not > seem right. > According to this paper, gcc should operate on double precision (64 > bit), or at > least give the impression that it does so (to the outside viewer). But > gcc operates > on a mixed 80/64 bit setting, and that seems contradictory to IEEE spirit > (and, probably, agains ISO C rules). > Among the remedies available would be a) set 53-bit rounding mode b) choose -msse2, for appropriate targets -- Tim Prince