Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Double multiplication differs between compile time and runtime in 32 bit platform

I'm compiling and running the following program in 32 and 64 bit platforms:

int main()
{
  double y = 8.34214e08;
  double z = 1.25823e45;

  return y * z == 8.34214e08 * 1.25823e45;
}

While in 64bit the result is the expected (the values are the same and the exit code is non-zero) in 32bit seems there is a little difference between the value calculated at compile time, the right hand side of the comparison, and the left side computed at runtime.

Is this a bug in the compiler or there is a logical explanation?

EDIT: this is different from Why comparing double and float leads to unexpected result? because here all the values are double.

like image 279
waj Avatar asked Jul 14 '15 22:07

waj


People also ask

What is compile time and runtime time?

Compile time is the programming lifecycle phase that converts the source code into an executable file. Runtime is the time when a program is running, in contrast to other program lifecycle phases such as compile time, link time, and load time. Compile time errors are syntax and semantic errors. Runtime errors are known as exceptions.

What is the difference between runtime polymorphism and compile time polymorphism?

Java. The following table demonstrates the difference between runtime polymorphism and compile-time polymorphism: In Compile time Polymorphism, the call is resolved by the compiler. In Run time Polymorphism, the call is not resolved by the compiler.

What are the differences between compile-time and run-time errors?

The Differences between Compile-Time and Run-Time Error are: Compile-Time Errors. Runtime-Errors. These are the syntax errors which are detected by the compiler. These are the errors which are not detected by the compiler and produce wrong results.

What are compile time errors in C++?

These errors occur when we violate the rules present in a syntax. The compile-time error indicates something that we need to fix before compiling the code. A compiler can easily detect these errors. It is the reason why we call them compile-time errors.


2 Answers

IEEE-754 allows intermediate computations to be done in a greater precision (emphasis mine).

(IEEE-754:2008) "A language standard should also define, and require implementations to provide, attributes that allow and disallow value-changing optimizations, separately or collectively, for a block. These optimizations might include, but are not limited to: [...] Use of wider intermediate results in expression evaluation."

In your case for example on a IA-32, the double values could be stored in the x87 FPU registers with greater precision (80-bit instead of 64). So you are actually comparing a multiplication done on double precision with a multiplication done on double-extended precision.

For example, on x64 where the result is 1 (the x87 FPU is not used as SSE is used instead), adding gcc option -mfpmath=387 to use the x87 makes the result change to 0 on my machine.

And if you wonder if that is also allowed by C, it is:

(C99, 6.3.1.p8) "The values of floating operands and of the results of floating expressions may be represented in greater precision and range than that required by the type;"

like image 161
ouah Avatar answered Oct 16 '22 07:10

ouah


In general, never do equality checks with floating point numbers. You need to check whether the result you want differs from the result you get by less than a pre-set precision.

What is happening here is in all likelihood due to the multiplication being run on two different "platforms": once by your code, and once by the compiler, which may have a different precision. This happens with most compilers.

Your program would probably work if you compiled it with the same options that were used to compile the compiler (supposing the compiler was compiled by itself). But that would not mean you would get the correct result; you would be getting the same precision error the compiler is getting.

(Also, I'm assuming that the compiler performs a straight multiplication and the parsing code recognizing floats does not enter into the equation. This might well be wishful thinking on my part).

Testing

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-4.8 --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 4.8.3 20141208 [gcc-4_8-branch revision 218481] (SUSE Linux)



#include <stdio.h>

int main()
{
  double y = 8.34214e08;
  double z = 1.25823e45;

 return  printf("%s\n", y * z == 8.34214e08 * 1.25823e45 ? "Equal" : "NOT equal!");
}

Forcing -O0 to avoid the compiler from optimizing out the whole code (thanks @markgz!), we get

$ gcc -m32 -O0 -o float float.c && ./float NOT equal! $ gcc -m32 -frounding-math -O0 -o float float.c && ./float Equal

For the record, since you got there before me :-),

-frounding-math

Disable transformations and optimizations that assume default floating-point rounding behavior. This is round-to-zero for all floating point to integer conversions, and round-to-nearest for all other arithmetic truncations. This option should be specified for programs that change the FP rounding mode dynamically, or that may be executed with a non-default rounding mode. This option disables constant folding of floating-point expressions at compile time (which may be affected by rounding mode) and arithmetic transformations that are unsafe in the presence of sign-dependent rounding modes.

The default is -fno-rounding-math.

like image 32
LSerni Avatar answered Oct 16 '22 06:10

LSerni