Hi, The small example below gives an incorrect result on 32 bit platforms. Both tests should lead to the same result, but one is false, the other is true. tested with the following compilers, all of them exhibiting the bug: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) Reading specs from /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=x86_64-redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42) Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java,pascal --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk) Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,java,f77 --enable-java-awt=gtk --host=x86_64-redhat-linux Thread model: posix gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) Compilation command, on 32 bits systems: gcc -o testgcc testgcc.cpp -lstdc++ Compilation command, on 64 bits systems: gcc -m32 -o testgcc testgcc.cpp -lstdc++ NOTE: on 64 bits systems, 64bit executable run as expected. Regards, Richard. ------------------testgcc.cpp--------------------------------------- #include <iostream> using std::cerr ; class BugMe { public: BugMe( double start, double step ) ; double value( int i ) const ; bool bugme( const BugMe* other ) ; private: double start_ ; double step_ ; } ; BugMe::BugMe(double start, double step) : start_(start), step_(step) { } double BugMe::value(int i) const { return start_ + i*step_ ; } bool BugMe::bugme( const BugMe* other ) { bool b1 = (value(44) == other->value(44)) ; double v1 = value(44) ; double v2 = other->value(44) ; bool b2 = (v1==v2) ; return b1 != b2 ; } main() { BugMe* b1 = new BugMe(123, 2345.54) ; BugMe* b2 = new BugMe(123, 2345.54) ; if( b1->bugme(b2) ) { cerr << "BUG!\n" ; } } ------------------testgcc.cpp---------------------------------------
This is a dup of bug 323. The problem is excessive precission. *** This bug has been marked as a duplicate of 323 ***
(In reply to comment #1) > This is a dup of bug 323. The problem is excessive precission. > > *** This bug has been marked as a duplicate of 323 *** Hi, Looking at the thread for bug #323 it would seem to happen only if optimization is turned on. in my case the bug is there even with -g2 -O0 -ffloat-store added to the compile line. Regards, Richard.
Only happens on x86.
(In reply to comment #3) > Only happens on x86. True. But only with gcc. Under Windows M$ .NET and DevStudio 6 give a correct result if "Improve float consitency" is turned on. Haven't tried with the Intel compiler yet. Will do from home. Regards, Richard.
Really comparing two floating point with equallity is not a good thing to do. This again is a dup of bug 323. *** This bug has been marked as a duplicate of 323 ***