Bug 31008 - float value not equal to itself after assignment
Summary: float value not equal to itself after assignment
Status: RESOLVED DUPLICATE of bug 323
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.1.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-01 13:42 UTC by Andrew Church
Modified: 2007-03-01 16:43 UTC (History)
46 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Church 2007-03-01 13:42:05 UTC
When compiling with optimization, it is possible to assign the value of one float variable to another, and then have the latter value compare unequal to the former. Take the following (contrived) testcase:

extern float sqrtf(float);
volatile int foo(int n) {
    float a = sqrtf(n);
    volatile float b = 0;
    int c = 0;
    while (b < a) {
        b = a;
        c++;
    }
    return c;
}
int main() {
    return foo(32)==1 ? 0 : 1;
}

In theory, the loop in foo() should execute once, but when compiled with -O1 or greater on i386, the loop never terminates. Examination of the generated assembly shows that "a" is retained on the floating-point stack and never flushed to memory, so when "b" is reloaded for the comparison, its value is slightly less than the more-precise "a". (While libm's sqrtf() may also be at fault for returning a value that was not properly converted to float, the same problem exists when the test program is compiled with -ffast-math to use the fsqrt instruction directly: the high-precision result of fsqrt is left on the stack for the comparison, without being converted to a single-precision value.)
Comment 1 Richard Biener 2007-03-01 16:43:33 UTC

*** This bug has been marked as a duplicate of 323 ***