g++ math difference between ARM and INTEL platforms - math

Question

The following program gives 8191 on INTEL platforms. On ARM platforms, it gives 8192 (the correct answer).
// g++ -o test test.cpp
#include <stdio.h>
int main( int argc, char *argv[])
{
double a = 8192.0 / (4 * 510);
long x = (long) (a * (4 * 510));
printf("%ld\n", x);
return 0;
}
Can anyone explain why? The problem goes away if I use any of the -O, -O2, or -O3 compile switches.
Thanks in advance!

Answer 1

long fun ( void )
{
double a = 8192.0 / (4 * 510);
long x = (long) (a * (4 * 510));
return(x);
}
g++ -c -O2 fun.c -o fun.o
objdump -D fun.o
0000000000000000 <_Z3funv>:
0: b8 00 20 00 00 mov $0x2000,%eax
5: c3 retq
No math, the compiler did all the math removing all of the dead code you had supplied.
gcc same deal.
0000000000000000 <fun>:
0: b8 00 20 00 00 mov $0x2000,%eax
5: c3 retq
arm gcc optimized
00000000 <fun>:
0: e3a00a02 mov r0, #8192 ; 0x2000
4: e12fff1e bx lr
the raw binary for the double a is
0x40101010 0x10101010
and double(4*510) is
0x409FE000 0x00000000
those are computations done at compile time even unoptimized.
generic soft float arm
00000000 <fun>:
0: e92d4810 push {r4, fp, lr}
4: e28db008 add fp, sp, #8
8: e24dd014 sub sp, sp, #20
c: e28f404c add r4, pc, #76 ; 0x4c
10: e8940018 ldm r4, {r3, r4}
14: e50b3014 str r3, [fp, #-20]
18: e50b4010 str r4, [fp, #-16]
1c: e24b1014 sub r1, fp, #20
20: e8910003 ldm r1, {r0, r1}
24: e3a02000 mov r2, #0
28: e59f3038 ldr r3, [pc, #56] ; 68 <fun+0x68>
2c: ebfffffe bl 0 <__aeabi_dmul>
30: e1a03000 mov r3, r0
34: e1a04001 mov r4, r1
38: e1a00003 mov r0, r3
3c: e1a01004 mov r1, r4
40: ebfffffe bl 0 <__aeabi_d2iz>
44: e1a03000 mov r3, r0
48: e50b3018 str r3, [fp, #-24]
4c: e51b3018 ldr r3, [fp, #-24]
50: e1a00003 mov r0, r3
54: e24bd008 sub sp, fp, #8
58: e8bd4810 pop {r4, fp, lr}
5c: e12fff1e bx lr
60: 10101010 andsne r1, r0, r0, lsl r0
64: 40101010 andsmi r1, r0, r0, lsl r0
68: 409fe000 addsmi lr, pc, r0
6c: e1a00000 nop ; (mov r0,
intel
0000000000000000 <fun>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 48 b8 10 10 10 10 10 movabs $0x4010101010101010,%rax
b: 10 10 40
e: 48 89 45 f0 mov %rax,-0x10(%rbp)
12: f2 0f 10 4d f0 movsd -0x10(%rbp),%xmm1
17: f2 0f 10 05 00 00 00 movsd 0x0(%rip),%xmm0 # 1f <fun+0x1f>
1e: 00
1f: f2 0f 59 c1 mulsd %xmm1,%xmm0
23: f2 48 0f 2c c0 cvttsd2si %xmm0,%rax
28: 48 89 45 f8 mov %rax,-0x8(%rbp)
2c: 48 8b 45 f8 mov -0x8(%rbp),%rax
30: 5d pop %rbp
31: c3 retq
0000000000000000 <.rodata>:
0: 00 00 add %al,(%rax)
2: 00 00 add %al,(%rax)
4: 00 e0 add %ah,%al
6: 9f lahf
7: 40 rex
so you can see in the arm that it is taking the 4.whatever (a value) and the 4*510 converted to double value and passing those into aeabi_dmul (double multiply no doubt). Then it converts that from double to integer (d2i) and there you go.
Intel same deal but with hard float instructions.
So if there is a difference (I would have to prep and fire up an arm to see at least one arm result, already have posted that my intel result for your program verbatim is 8192) would be in one of the two floating point operations (multiply or double to integer) and rounding choices may come into play.
this is oviously not a value that can be represented cleanly in base two (floating point).
0x40101010 0x10101010
start doing math with that and one of those ones may cause a rounding difference.
last and most important, just because the pentium bug was famous, and we were lead to believe they fixed it, floating point units still have bugs...But usually the programmer falls into a floating point accuracy trap before then which is likely what you are seeing here if you are actually seeing anything here...

Answer 2

The reason your problem goes away if you use optimisation flags is because this result is known a priori, i.e. the compiler can just replace x in the printf statement with 8192 and save memory. In fact, I'm willing to bet money that it's the compiler that's responsible for the differences you observe.
This question is essentially 'how do computers store numbers', and that question is always is relevant to programming in C++ (or C). I recommend you look at the link before reading further.
Let's look at these two lines:
double a = 8192.0 / (4 * 510);
long x = (long) (a * (4 * 510));
For a start, note that you're multiplying two int constants together -- implicitly, 4 * 510 is the same as (int)(4 * 150). However, C (and C++) has a happy rule that, when people write things like a/3, the calculation is done in floating-point arithmetic rather than with integer arithmetic. The calculation is done in double unless both operands are float, in which case the calculation is done in float, and integer if both operands are ints. I suspect that you might be running into precision issues for your ARM target. Let's make sure.
For the sake of my own curiosity, I've compiled your program to assembly, by calling gcc -c -g -Wa,-a,-ad test.c > test.s. On two different versions of GCC, both of them on Unix-like OSes, this snippet always ejects 8192 rather than 8191.
This particular combination of flags includes the corresponding line of C as an assembly comment, which makes it much easier to read what's happening. Here's the interesting bits, written in AT&T Syntax, i.e. commands have the form command source, destination.
30 5:testSpeed.c **** double a = 8192.0 / (4 * 510);
31 23 .loc 1 5 0
32 24 000f 48B81010 movabsq $4616207279229767696, %rax
33 24 10101010
34 24 1040
35 25 0019 488945F0 movq %rax, -16(%rbp)
Yikes! Let's break this down a bit. Lines 30 to 36 deal with the assignment of the quad-byte value 4616207279229767696 to the register rax, a processor register that holds values. The next line -- movq %rax, -16(%rbp) -- moves that data into a location in memory pointed to by rbp.
So, in other words, the compiler has assigned a to memory and forgotten about it.
The next set of lines are a bit more complicated.
36 6:testSpeed.c **** long x = (long) (a * (4 * 510));
37 26 .loc 1 6 0
38 27 001d F20F104D movsd -16(%rbp), %xmm1
39 27 F0
40 28 0022 F20F1005 movsd .LC1(%rip), %xmm0
41 28 00000000
42 29 002a F20F59C1 mulsd %xmm1, %xmm0
43 30 002e F2480F2C cvttsd2siq %xmm0, %rax
44 30 C0
45 31 0033 488945F8 movq %rax, -8(%rbp)
...
72 49 .LC1:
73 50 0008 00000000 .long 0
74 51 000c 00E09F40 .long 1084219392
75 52 .text
76 53 .Letext0:
Here, we start off by moving the contents of the register pointed to above -- i.e. a -- to a register (xmm1). We then take the data pointed to in the snipped I've shown below, .LC1, and jam it into another register (xmm0). Much to my surprise, we then do a scalar floating-point double precision multiply (mulsd). We then truncate the result (which is what your cast to long actually does by calling cvttsd2siq, and put the result somewhere (movq %rax, -8(%rbp)).
46 7:testSpeed.c **** printf("%ld\n", x);
47 32 .loc 1 7 0
48 33 0037 488B45F8 movq -8(%rbp), %rax
49 34 003b 4889C6 movq %rax, %rsi
50 35 003e BF000000 movl $.LC2, %edi
51 35 00
52 36 0043 B8000000 movl $0, %eax
53 36 00
54 37 0048 E8000000 call printf
55 37 00
56 8:testSpeed.c **** return 0;
The remainder of this code then just calls printf.
Now, let's do the same thing again, but with -O3, i.e. telling the compiler to be rather aggressively optimising. Here's a few choice snippets from the resulting assembly:
139 22 .loc 2 104 0
140 23 0004 BA002000 movl $8192, %edx
...
154 5:testSpeed.c **** double a = 8192.0 / (4 * 510);
155 6:testSpeed.c **** long x = (long) (a * (4 * 510));
156 7:testSpeed.c **** printf("%ld\n", x);
157 8:testSpeed.c **** return 0;
158 9:testSpeed.c **** }
...
In this instance, we see that the compiler hasn't even bothered to produce instructions from your code, and instead just inlines the right answer.
For the sake of argument, I did the same thing with long x=8192; printf("%ld\n",x);. The assembly is identical.
Something similar will happen for your ARM target, but the floating-point multiplies are different because it's a different processor (everything above only holds true for x86_64). Remember, if you see something you don't expect with C (or C++) programming, you need to stop and think about it. Fractions like 0.3 cannot be represented finitely in memory!