GCC Bugzilla Bug 14652

Consider the following lines of code:

> rgData->sampleWindow = (long) ceil (samplefreq * 0.050);
> printf("%ld\n", rgData->sampleWindow);

samplefreq is of type long and is equal to 44100
rgData->sampleWindow is of type long

Simple math: 44100 * 0.050 = 2205

If compiled without optimization (-O) the code above returns the correct value of:
2205

If compiled with optimization (-O), the code above returns:
2206

Now the really buggy and funny part. The same calculation twice:
> rgData->sampleWindow = (long) ceil (samplefreq * 0.050);
> printf("%ld\n", rgData->sampleWindow);
> rgData->sampleWindow = (long) ceil (samplefreq * 0.050);
> printf("%ld\n", rgData->sampleWindow);

Without optimization it returns:
2205
2205

With optimization it returns:
2206
2205

My further investigation showed that it is the ceil() function that is
responsible. It returns indeterministic results! In one line it returns 2206, in
another 2205, within the same program! 

Besides I really think that the code should not only be deterministic, it should
return the same value of 2205 both with and without optimization, because a the
wrong value of 2206 might have catastrophic results for some code.

I checked that the same bug is present in gcc-3.3.3-20040125-(prerelease)-Debian. 

I also checked that a similar bug is present in 
gcc-2.95.4-20011002-(prerelease)-Debian
with the exception that:
1. without optimization the code returns 2205
2. with optimization the code always returns 2206 (not sometimes 2205, sometimes
2206, like with the other versions)


I prepared a testcase for gcc-3.0.4 with the ceil() function run twice, like
above. It should return:
2206
2205


Here is the complete output of gcc -v -save-temps:
$ gcc -v -save-temps -Wall -o gain_analysis -O -lm gain_analysis.c
Reading specs from /usr/lib/gcc-lib/i386-linux/3.0.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,proto,objc --prefix=/usr --infodir=/share/info
--mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld
--with-system-zlib --enable-long-long --enable-nls --without-included-gettext
--disable-checking --enable-threads=posix --enable-java-gc=boehm
--with-cpp-install-dir=bin --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.0.4
 /usr/lib/gcc-lib/i386-linux/3.0.4/cpp0 -lang-c -v -D__GNUC__=3
-D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=4 -D__ELF__ -Dunix -Dlinux -D__ELF__
-D__unix__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__OPTIMIZE__
-D__STDC_HOSTED__=1 -Wall -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__
-D__tune_i386__ gain_analysis.c gain_analysis.i
GNU CPP version 3.0.4 (cpplib) (i386 Linux/ELF)
ignoring nonexistent directory "/usr/i386-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc-lib/i386-linux/3.0.4/include
 /usr/include
End of search list.
In file included from gain_analysis.c:16:
machine.h:32:1: warning: "strchr" redefined
/usr/include/bits/string2.h:390:1: warning: this is the location of the previous
definition
 /usr/lib/gcc-lib/i386-linux/3.0.4/cc1 -fpreprocessed gain_analysis.i -quiet
-dumpbase gain_analysis.c -O -Wall -version -o gain_analysis.s
GNU CPP version 3.0.4 (cpplib) (i386 Linux/ELF)
GNU C version 3.0.4 (i386-linux)
        compiled by GNU C version 3.0.4.
 as -V -Qy -o gain_analysis.o gain_analysis.s
GNU assembler version 2.14.90.0.7 (i386-linux) using BFD version 2.14.90.0.7
20031029 Debian GNU/Linux
 /usr/lib/gcc-lib/i386-linux/3.0.4/collect2 -m elf_i386 -dynamic-linker
/lib/ld-linux.so.2 -o gain_analysis
/usr/lib/gcc-lib/i386-linux/3.0.4/../../../crt1.o
/usr/lib/gcc-lib/i386-linux/3.0.4/../../../crti.o
/usr/lib/gcc-lib/i386-linux/3.0.4/crtbegin.o -L/usr/lib/gcc-lib/i386-linux/3.0.4
-L/usr/lib/gcc-lib/i386-linux/3.0.4/../../.. -lm gain_analysis.o -lgcc -lc -lgcc
/usr/lib/gcc-lib/i386-linux/3.0.4/crtend.o
/usr/lib/gcc-lib/i386-linux/3.0.4/../../../crtn.o


I will attach gain_analysis.i.

Created an attachment (id=5945) [edit]
testcase as in the description of the bug

This is dup of bug 323 as the problem is that in one call to ceil it is using
the extended precission while 
in the other it roundded it.

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