Platform: i686 Linux 2.6.11
> gcc -v
Using built-in specs.
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-126.96.36.199/jre --host=i386-redhat-linux
Thread model: posix
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
According to the C++ standard section 5.2.9/2, the result of casting an
expression to float is as if a temporary variable of type float were
declared and initialized with that expression, and then used in place
of the expression.
That seems to be violated in the program below when compiled in non debug mode (gcc test.c) The program a.out prints 1 instead of 0.
In optimized mode (gcc -O test.c) the program prints 0 correctly. Same thing with -O2.
Same result when renaming the file test.cpp and compiling with g++ and also when using static_cast instead of C-style casts.
In the program below, the functions foo1() and foo2() should always produce the same result. But the assembly code for foo2() differs from foo1() by two extra lines (fstps and flds) when compiled in non-optimized mode.
int foo1(int x)
int foo2(int x)
float f = x;
int i = 0x1000001; /* i == 16777217 */
int u = foo1(i) - foo2(i);
this is a dup of bug 323. The issue is more complex than you think, even though in this case you get the same answer for the optimized case and not for the unoptimized case. Using -ffloat-store will get you a zero for the unoptimized case.
*** This bug has been marked as a duplicate of 323 ***