other/10417: Inconsistent results in floating point comparison.

[csk@cgl.uwaterloo.ca]

>Number:         10417
>Category:       other
>Synopsis:       Inconsistent results in floating point comparison.
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 15 19:06:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     csk@cgl.uwaterloo.ca
>Release:        3.2.1, 2.95.4
>Organization:
>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?

Moreover, the program always prints a 0 when compiled with optimization.  This inconsistency relative to the unoptimized version might indeed constitute a bug.

Anyway, it's not totally clear to me that this is a bug.  But either way, I'd love for someone in GCC land to explain to me what's going on.  Thanks.

p.s. The bug remains if you switch from doubles to floats.   
     And I have a slightly larger program that exhibits the inconsistent behaviour when optimization is turned _on_.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: