Re: [Valgrind-users] Floating point DATA CORRUPTION with 80bit long long double!! (Re: floating point print error in ada)

[Irek S. <isz...@gm...>]

On Wed, Mar 6, 2013 at 10:19 AM,  <pa...@fr...> wrote:
> ----- Original Message -----
>
> [snip]
>
> I'll start with a few general comments. I've been working on engineering software for most of my career, and with very few exceptions, double precision is perfectly adequate (and the fastest).
>
> The real world (at least, the Intel/AMD part of it) is somewhat complicated by there being two floating point coprocessors, the venerable x87 and SSE. By default, 32bit compiles use x87 and 64bit compiles use SSE. SSE is fairly straightforward: if you use doubles, all calculations are done at 64bit precision. x87 uses 80bit for internal calculations and converts the final result to 64bit. GCC does have an option, -ffloat-store, that inhibits this behaviour (and decent performance!). But there is more. You can compile in mixed x87/sse (though I've found this to be somewhat error prone if you also play with the floating point control and status flags). Lastly, if you do compile with sse on 32bit, by default you will link with the x87 based libm part of the standard C library. Again, GCC has an option to link with an sse version of libm, -msselibm.
>
> What is the upshot of all this?
>
> If you compile on both 32bit and 64bit platforms without changing the default options, you will get different results.
>
> Now, let Valgrind enter the picture. All calculations are done at 64bit, so there should be little or no change on 64bit platforms using sse. However, 32bit platforms using x87 will probably change to give the same results obtained with 64bit and sse.
>
>> Uh. The impact here is DATA CORRUPTION, caused by doing calculations
>> to be meant using 80bit datatypes being done with 64bit datatypes and
>> the remaining bits filled with garbage.
>>
>> If this can't be solved or is not going to be solved then valgrind
>> should ABORT instead of causing a silent corruption of data.
>
> Is this really true? I would expect that Valgrind does all calculations at 64bit double precision and converts. This will result in truncation and/or under/overflow.
>
> My feeling is that unless the usually small numerical differences change your control flow, then just ignore the differences. The aim of testing with Valgrind isn't to validate numerical results, it is to validate memory use or performance or threading.

Unfortunately the assessment that there are only "small changes" or
"unimportant differences" is plain wrong. In complex calculations
(i.e. no one line "hello sin() world" demo apps) which rely on the
wider datatypes the lack of precision will cause major malfunctions
and render the applications defunct. There are enough examples for
this kind of problems (and enough complains about valgrind in the NIH
lists).

Irek