C++: doubles, precision, virtual machines and GCC - c++

Question

I have the following piece of code:
#include <cstdio>
int main()
{
if ((1.0 + 0.1) != (1.0 + 0.1))
printf("not equal\n");
else
printf("equal\n");
return 0;
}
When compiled with O3 using gcc (4.4,4.5 and 4.6) and run natively (ubuntu 10.10), it prints the expected result of "equal".
However the same code when compiled as described above and run on a virtual machine (ubuntu 10.10, virtualbox image), it outputs "not equal" - this is the case for when the O3 and O2 flags are set however not O1 and below. When compiled with clang (O3 and O2) and run upon the virtual machine I get the correct result.
I understand 1.1 can't be correctly represented using double and I've read "What Every Computer Scientist Should Know About Floating-Point Arithmetic" so please don't point me there, this seems to be some kind of optimisation that GCC does that somehow doesn't seem to work in virtual machines.
Any ideas?
Note: The C++ standard says type promotion in this situations is implementation dependent, could it be that GCC is using a more precise internal representation that when the inequality test is applied holds true - due to the extra precision?
UPDATE1: The following modification of the above piece of code, now results in the correct result. It seems at some point, for whatever reason, GCC turns off floating point control word.
#include <cstdio>
void set_dpfpu() { unsigned int mode = 0x27F; asm ("fldcw %0" : : "m" (*&mode));
int main()
{
set_dpfpu();
if ((1.0 + 0.1) != (1.0 + 0.1))
printf("not equal\n");
else
printf("equal\n");
return 0;
}
UPDATE2: For those asking about the const expression nature of the code, I've changed it as follows, and still fails when compiled with GCC. - but i assume the optimizer may be turning the following into a const expression too.
#include <cstdio>
void set_dpfpu() { unsigned int mode = 0x27F; asm ("fldcw %0" : : "m" (*&mode));
int main()
{
//set_dpfpu(); uncomment to make it work.
double d1 = 1.0;
double d2 = 1.0;
if ((d1 + 0.1) != (d2 + 0.1))
printf("not equal\n");
else
printf("equal\n");
return 0;
}
UPDATE3 Resolution: Upgrading virtualbox to version 4.1.8r75467 resolved the issue. However the their remains one issue, that is: why was the clang build working.

Answer 1

UPDATE: See this posting How to deal with excess precision in floating-point computations?
It address the issues of extended floating point precision. I forgot about the extended precision in x86. I remember a simulation that should have been deterministic, but gave different results on Intel CPUs than on PowePC CPUs. The causes was Intel's extended precision architecture.
This Web page talks about how to throw Intel CPUs into double-precision rounding mode: http://www.network-theory.co.uk/docs/gccintro/gccintro_70.html.
Does virtualbox guarantee that its floating point operations are identical to the the hardware's floating point operations? I could not find a guarantee like that with a quick Google search. I also did not find a promise that vituralbox FP ops conform to IEEE 754.
VMs are emulators that try-- and mostly succeed-- to the emulate a particular instruction set or architecture. They are just emulators, however, and subject to their own implementation quirks or design issues.
If you haven't already, post the question forums.virtualbox.org and see what the community says about it.

Answer 2

Yep that is really strange behavior, but it can actually easily be explained:
On x86 floating point registers internally use more precision (eg 80 instead of 64). This means the computation 1.0 + 0.1 will be computed with more precision (and since 1.1 can't be represented exactly in binary at all those extra bits WILL be used) in the registers. Only when storing the result to memory will it be truncated.
What this means is simple: If you compare a value loaded from memory with a value newly computed in the registers you'll get a "non-equal" back, because one value was truncated while the other wasn't. So that has nothing to do with VM/no VM it just depends on the code the compiler generates which can easily fluctuate as we see there.
Add it to the growing list of floating point surprises..

Answer 3

I can confirm the same behaviour of your non-VM code, but since I don't have a VM I haven't tested the VM part.
However, the compiler, both Clang and GCC will evaluate the constant expression at compile time. See the assembly output below (using gcc -O0 test.cpp -S) :
.file "test.cpp"
.section .rodata
.LC0:
.string "equal"
.text
.globl main
.type main, #function
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $.LC0, %edi
call puts
movl $0, %eax
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident "GCC: (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1"
.section .note.GNU-stack,"",#progbits
It looks like you understand assembly, but it's clear that there is only the "equal" string, there is no "not equal". So the comparison is not even done at run time, it just prints "equal".
I would try to code the calculation and comparison using assembly and see if you have the same behavior. If you have different behavior on the VM, then it's the way the VM does the calculation.
UPDATE 1: (Based on the "UPDATE 2" in the original question). Below is the gcc -O0 -S test.cpp output assembly (for 64 bit architecture). In it you can see the movabsq $4607182418800017408, %rax line twice. This will be for the two comparison flags, I haven't verified, but I presume the $4607182418800017408 value is 1.1 in floating point terms. It would be interesting to compile this on the VM, if you get the same result (two similar lines) then the VM will be doing something funny at run-time, otherwise it's a combination of VM and compiler.
main:
.LFB1:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
subq $16, %rsp
movabsq $4607182418800017408, %rax
movq %rax, -16(%rbp)
movabsq $4607182418800017408, %rax
movq %rax, -8(%rbp)
movsd -16(%rbp), %xmm1
movsd .LC1(%rip), %xmm0
addsd %xmm1, %xmm0
movsd -8(%rbp), %xmm2
movsd .LC1(%rip), %xmm1
addsd %xmm2, %xmm1
ucomisd %xmm1, %xmm0
jp .L6
ucomisd %xmm1, %xmm0
je .L7

Answer 4

I see you added another question:
Note: The C++ standard says type promotion in this situations is implementation dependent, could it be that GCC is using a more precise internal representation that when the inequality test is applied holds true - due to the extra precision?
The answer to that one is no. 1.1 is not exactly representable in a binary format, no matter how many bits the format has. You can get close, but not with an infinite number of zeros after the .1.
Or did you mean an entirely new internal format for decimals? No, I refuse to believe that. It wouldn't be very compatible if it did.