From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14699 invoked by alias); 3 Jun 2002 13:16:13 -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 14670 invoked by uid 71); 3 Jun 2002 13:16:10 -0000 Date: Mon, 03 Jun 2002 06:16:00 -0000 Message-ID: <20020603131610.14669.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Michael Veksler Subject: Re: c++/6914: -O2 and -O give different results for the same valid FP code Reply-To: Michael Veksler X-SW-Source: 2002-06/txt/msg00063.txt.bz2 List-Id: The following reply was made to PR c++/6914; it has been noted by GNATS. From: Michael Veksler To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, veksler@il.ibm.com, gcc-bugs@gcc.gnu.org Cc: Subject: Re: c++/6914: -O2 and -O give different results for the same valid FP code Date: Mon, 03 Jun 2002 16:09:30 +0300 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). You can read the section about optimization.