See description and how to repeat below: kostja@dragonfly:~> cat foo.c #include <stdio.h> int i; void foo(long long l, void *buf) { float f= (float) l; i= (long long) f != l; *(float*) buf= f; } int main() { float f; long long l= 1073741825; foo(l, &f); printf("%lld %d %f\n", l, i, f); } kostja@dragonfly:~> gcc foo.c; ./a.out 1073741825 1 1073741824.000000 kostja@dragonfly:~> gcc -O1 foo.c; ./a.out 1073741825 0 1073741824.000000 kostja@dragonfly:~> gcc -O3 foo.c; ./a.out 1073741825 0 1073741825.000000 kostja@dragonfly:~> gcc -O3 -ffloat-store foo.c; ./a.out 1073741825 1 1073741824.000000 kostja@dragonfly:~> gcc -v Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --enable-threads=posix --enable-language=c,c++ : (reconfigured) ../gcc-3.4.3/configure --enable-threads=posix --enable-languages=c,c++ : (reconfigured) ../gcc-3.4.3/configure --enable-threads=posix --enable-languages=c,c++ Thread model: posix gcc version 3.4.3 While I see no problem with cases 1 and 3, the case 2 (-O1) seems to be broken: gcc fails to check that truncation happened, although it's there. Environment: System: Linux dragonfly 2.6.5-7.108-default #1 Wed Aug 25 13:34:40 UTC 2004 i686 i686 i386 GNU/Linux Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: ../gcc-3.4.3/configure --enable-threads=posix --enable-language=c,c++ : (reconfigured) ../gcc-3.4.3/configure --enable-threads=posix --enable-languages=c,c++ : (reconfigured) ../gcc-3.4.3/configure --enable-threads=posix --enable-languages=c,c++ How-To-Repeat: See the program given in description.
Fix: I know of no workaround.
*** This bug has been marked as a duplicate of 323 ***
Could you elaborate how comes that you are certain that the bug is a duplicate of #323? The problem as I described is that the comparison (line 8) reports success, while numbers are actually different, not the other way - failed comparison for equal (or expected-to-be-equal) numbers. Note that the comparison is performed against integer numbers, not floating point numbers. I guess the reason of the success is that the cast in the comparison somehow gets optimized away. Thank you.
(In reply to comment #3) > Could you elaborate how comes that you are certain that the bug is a duplicate > of #323? Easily the use of execusive precission is causing the problem which is what 323 is about. > > The problem as I described is that the comparison (line 8) reports success, > while numbers > are actually different, not the other way - failed comparison for equal (or > expected-to-be-equal) numbers. > Note that the comparison is performed against integer numbers, not floating > point numbers. > > I guess the reason of the success is that the cast in the comparison somehow > gets optimized away. No the cast is not being optimizated away, just it is being rounded differently. *** This bug has been marked as a duplicate of 323 ***
Try using -ffloat-store to get what you expect.