This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: other/10417: Inconsistent results in floating point comparison.
- From: Tim Prince <timothyprince at sbcglobal dot net>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 16 Apr 2003 04:56:01 -0000
- Subject: Re: other/10417: Inconsistent results in floating point comparison.
- Reply-to: Tim Prince <timothyprince at sbcglobal dot net>
The following reply was made to PR other/10417; it has been noted by GNATS.
From: Tim Prince <timothyprince at sbcglobal dot net>
To: csk at mud dot cgl dot uwaterloo dot ca, gcc-gnats at gcc dot gnu dot 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 at mud dot cgl dot uwaterloo dot 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