Description of problem: This issue arose from tracing a problem with an infinite loop in the startup of f7 build of xsane, the scanner software, but I've boiled the issue down to a tiny C program that can be compiled with or without optimisation and in each of those cases you can see that the generated executable gives a different result. Version-Release number of selected component (if applicable): Vigor12 2.6.22.1-41.fc7 gcc version 4.1.2 20070502 (Red Hat 4.1.2-12) How reproducible: always Steps to Reproduce: 1. Save the attached bug.c C program 2. Compile: gcc -o bug bug.c 3. Run: ./bug 4. Observe result 39019943 5. Compile: gcc -O2 -o buggo bug.c 6. Run: ./buggo 7. Observe result: 39019942 Also note that if you uncomment the commented printf statements in the attached C source, you get a different result!!!! Something is rather weird. Actual results: The two results were different Expected results: The two results should be the same
Created attachment 160796 [details] bug.c to reproduce the problem
This difference in behaviour is also visible in gcc 2.96 on an old linux.
That's caused by excess precision, not a bug, but a thing you need to take into account when programming i?87. See e.g. info gcc --index-search=ffloat-store or e.g. http://www.network-theory.co.uk/docs/gccintro/gccintro_70.html If this is undesirable in your program, you can either use -ffloat-store option which will slow down your program, but ensure every assignment to a double (or float) variable will do the rounding to that precision, or if you have sufficiently new CPU, compile with -msse2 -mfpmath=sse or if you have 64-bit x86_64 CPU, compile 64-bit.