Please read the "limitations" section of the manual at http://valgrind.org/docs/manual/manual-core.html#manual-core.limits especially the part about x86 floating point, and in particular this:

"Precision: There is no support for 80 bit arithmetic. Internally, Valgrind represents all such "long double" numbers in 64 bits, and so there may be some differences in results."

That is likely why your program behaves differently under valgrind.

Your program is essentially not well defined anyway though, as floating point calculations are always imprecise so you should not expect to be able to compare a floating point result for equality with an integer version of the same calculation.

No, this bug report is not about precision. Note that the crucial line is:

int comparison = (a == d || a < d || a > d);

Under valgrind, this evaluates to 0. This is only possible if a or d is NaN, but both numbers clearly aren't.

Although I'm not clear if that is what has happened here (and this should only happen when not running under valgrind) that's not actually true with x87 because if the compiler chooses to move one of the values from the FP stack to memory in the middle of the comparisons for any reason it will get converted from 80 bit to 64 bit and it's value will change...

You're correct. Given the statement

int comparison = (a == d || a < d || a > d);

and two values a and d in extended precision floating point registers that are very close to each other, and equal in double precision, the following could happen:

1. (a == d)  is evaluated with the extended precision values in registers, returning false.
2. The values are stored in memory and reloaded, casting them to double precision. The rounded double precision values are now equal.
3. (a < d) and (a > d) both return false.

And I think that's exactly what happens under Valgrind. IIUC, Valgrind doesn't support extended precision but before the floating state is saved in double precision, any instruction block still operates with extended precision.

(In reply to Tom Hughes from comment #3)
> Although I'm not clear if that is what has happened here (and this should
> only happen when not running under valgrind) that's not actually true with
> x87 because if the compiler chooses to move one of the values from the FP
> stack to memory in the middle of the comparisons for any reason it will get
> converted from 80 bit to 64 bit and it's value will change...

As a side note .. no .. x87 spills/reloads are done with 80-bit loads/stores,
exactly to avoid the situation that the values computed depend on the 
specifics of register allocation.

That said .. I'm not really clear what's going on here.  It might be some kind
of precision problem, given that there are only really 53 mantissa bits available
because V simulates 80 bit registers using normal double-precision values.
It would require further investigation.

Note that I didn't mean spills/reloads that valgrind's internal implementation does, but rather any spills/reloads that the original compiler generated.

My understanding was that those would use the normal memory location for the variable, which as a double would only be 64 bits and hence would lose precision. Are you saying that gcc instead allocates an 80 bit temporary location for the spill to avoid losing precision?

(In reply to Tom Hughes from comment #6)
> Note that I didn't mean spills/reloads that valgrind's internal
> implementation does, but rather any spills/reloads that the original
> compiler generated.

Yes -- that's also what I meant.

> Are you saying that gcc instead allocates an 80 bit temporary
> location for the spill to avoid losing precision?

Well I *thought* that was the case, but it seems I am wrong.  Using
this spill-inducing loop

  int main ( int argc, char** argv )
  {
     double a, b, c, d, e, f, g, h;
     a=b=c=d=e=f=g=h=1.2345;
     int i;
     for (i = 0; i < 1234 * argc; i++) {
        a += i * 1.2;
        b += a * 1.3;
        c += d / 1.4;
        d += e - 1.5;
        e += f + 1.6;
        f += g - 1.7;
        g += h * 1.8;
        h += a - (b*c) + (d*e*f/g);
     }
     return (a-b-c-d-e-f-g-h > 987.345 ? 1 : 0);
  }

I get the assembly (for the loop body) below, which uses 64-bit loads
and stores (fstpl -16(%ebp), fmull -16(%ebp), etc) with gcc6 -m32 -O2.
To get 80-bit accesses (fstpt, fldt) I need to change the declaration
to be "long double".

Ah well.  Live and learn.  Now I am wondering why I believed gcc did
always do 80-bit spills/reloads.

.L3:
        movl    %eax, -28(%ebp)
        addl    $1, %eax
        fildl   -28(%ebp)
        cmpl    %edx, %eax
        fmull   .LC1
        faddp   %st, %st(1)
        fldl    .LC2
        fmul    %st(1), %st
        faddl   -24(%ebp)
        fld     %st(0)
        fstpl   -24(%ebp)
        fldl    .LC3
        fdivr   %st(7), %st
        faddl   -16(%ebp)
        fstpl   -16(%ebp)
        fld     %st(3)
        fsubs   .LC4
        faddp   %st, %st(7)
        fldl    .LC5
        fadd    %st(5), %st
        faddp   %st, %st(4)
        fldl    .LC6
        fsubr   %st(6), %st
        faddp   %st, %st(5)
        fldl    .LC7
        fmul    %st(3), %st
        faddp   %st, %st(6)
        fld     %st(6)
        fmul    %st(4), %st
        fmul    %st(5), %st
        fdiv    %st(6), %st
        fxch    %st(1)
        fmull   -16(%ebp)
        fsubr   %st(2), %st
        faddp   %st, %st(1)
        faddp   %st, %st(2)
        jne     .L3