From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-33170-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 24027 invoked by alias); 16 Apr 2003 04:56:01 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 24004 invoked by uid 71); 16 Apr 2003 04:56:01 -0000
Date: Wed, 16 Apr 2003 04:56:00 -0000
Message-ID: <20030416045601.24003.qmail@sources.redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: Tim Prince <timothyprince@sbcglobal.net>
Subject: Re: other/10417: Inconsistent results in floating point comparison.
Reply-To: Tim Prince <timothyprince@sbcglobal.net>
X-SW-Source: 2003-04/txt/msg00740.txt.bz2
List-Id: <gcc-prs.sourceware.org>

The following reply was made to PR other/10417; it has been noted by GNATS.

From: Tim Prince <timothyprince@sbcglobal.net>
To: csk@mud.cgl.uwaterloo.ca, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: other/10417: Inconsistent results in floating point comparison.
Date: Tue, 15 Apr 2003 20:36:32 -0700

 On Tuesday 15 April 2003 12:01, csk@mud.cgl.uwaterloo.ca wrote:
 > >Number:         10417
 > >Category:       other
 > >Synopsis:       Inconsistent results in floating point comparison.
 
 > >Environment:
 >
 > Debian Woody, Pentium IV
 >
 > >Description:
 >
 > Witness the following short program:
 >
 > ---------------------
 > #include <stdio.h>
 > #include <stdlib.h>
 >
 > int main( int argc, char ** argv )
 > {
 >     double x = atof( argv[1] );
 >     double d = x*x;
 >
 >     printf( "%d\n", (x*x<d) );
 >     return 0;
 > }
 > -----------------------
 >
 > Ideally, this program should always print 0, since a number shouldn't be
 > strictly less than itself.  When compiled without optimization, the program
 > will print 0 or 1 depending on the input (I get 0.3 --> 0, 0.4 --> 1, for
 > instance).
 >
 > Now I understand that floating point numbers are far from ideal, and that
 > this behaviour might not be a bug.  Still, I would love to be able to
 > characterize for which numbers the program will print 0 or 1.  Any
 > thoughts?
 If you ask the compiler to generate x87 code (the probable default for your 
 configuration), it could interpret the expression as
 (long double)x*x < d;
 so the expression would be 1 every time d has been rounded up.
 If you use the command
 gcc -march=pentium4 -mfpmath=sse *.c
 as you might normally do for a P4, I doubt you could get the results you 
 mention. 
 >
 > Moreover, the program always prints a 0 when compiled with optimization. 
 > This inconsistency relative to the unoptimized version might indeed
 > constitute a bug.
 I can't reproduce this, unless I tell the compiler to generate x87 code. As I 
 don't "always" do that, I am not reproducing your claim. 
 >
 >
 -- 
 Tim Prince