Re: other/10417: Inconsistent results in floating point comparison.

[Tim Prince <timothyprince@sbcglobal.net>]

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