Bug 11892 - double to int different if intermediate double used and no optimisation
Summary: double to int different if intermediate double used and no optimisation
Status: RESOLVED DUPLICATE of bug 323
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.3.1
: P2 normal
Target Milestone: 3.4.0
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2003-08-12 10:02 UTC by Simon Marshall
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Simon Marshall 2003-08-12 10:02:18 UTC
I hesitate to submit this, but I don't think this merits the usual "what do you 
expect from doubles?" response.  This is with:

Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/specs
Configured with: ../configure --prefix=/usr/local --enable-
languages=c,c++,f77,objc,java,ada --enable-threads=posix --enable-shared --
enable-__cxa_atexit --with-system-zlib
Thread model: posix
gcc version 3.3.1

and the program:

#include <stdio.h>

int main ()
    double d = 0.1;
    double e = 5;
    double f = e / d;
    int i = (int) f;
    int j = (int) (e / d);

    printf ("f = %lf\n", f);
    printf ("i = %d\n", i);
    printf ("j = %d\n", j);

    return 0;

Notice that i and j are the integer result of 5 / 0.1 but that the intermediate 
double f is used to initialise i.  I can just about except that 0.1 is 
represented by 0.10000000000000001 according to gdb.  What does surprise me is 
that i and j can have different values:

$ gcc double.cpp && ./a.out
f = 50.000000
i = 50
j = 49
$ gcc -O double.cpp && ./a.out
f = 50.000000
i = 50
j = 50
$ gcc -O -ffloat-store double.cpp && ./a.out
f = 50.000000
i = 50
j = 49

As you can see, i != j unless I use raw optimisation.  I can just about except 
that the result of the arithmetic is not exactly 50, but surely i should always 
be equal to j?  In other words, I think i==j==50 or i==j==49 are correct 
outcomes but i!=j is not.
Comment 1 Andrew Pinski 2003-08-12 12:51:33 UTC
This is caused by x86's rounding modes and excessive precision so it is a dup of bug 323.

*** This bug has been marked as a duplicate of 323 ***
Comment 2 Simon Marshall 2003-08-12 14:31:14 UTC
Thanks for the quick response.  I see that floating-point bugs are frequently 
raised and closed against 323.

I'm not 100% sure it is exactly the same but 100% sure that I'm stuck.  The 
suggestion for 323 is to use -ffloat-store.  Unfortunately, for this problem it 
actually makes things worse (when used with optimisation) and makes no 
difference (when used without optimisation).  It also suggests to change the fp 
rounding mode, but the gcc info doesn't seem to mention anything for that with 

The M$ compiler has no problem with my code.  How does it do it?  How can I 
make gcc do it?  If there is no way to make gcc do it, then surely it is a bug 
or at least a missing feature?