Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

[Lionel C. <lio...@gm...>]

On 29 January 2014 21:54, Tina Harriott <tin...@gm...> wrote:
> On 22 January 2014 22:36, Philippe Waroquiers
> <phi...@sk...> wrote:
>> On Wed, 2014-01-22 at 00:19 +0100, Lionel Cons wrote:
>>> On 22 January 2014 00:03, Tom Hughes <to...@co...> wrote:
>>> > On 21/01/14 21:49, Tina Harriott wrote:
>>> >
>>> >> I am new to this list. Can anyone guide me dissect a problem with
>>> >> valgrinds long double fp math on x86-64 cpus? We're getting major
>>> >> malfunctions in our applications because any long double operation
>>> >> (say y=sinl(x)) contains rubbish in the least significant bits.
>>> >
>>> > See the "Limitations" section of the manual:
>>> >
>>> >    http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits
>>> >
>>> > Specifically the section about floating point limitations.
>>>
>>> "...Whether or not this is critical remains to be seen..."
>>>
>>> Yeah, that comment is so 'funny' that it hurts again. The difference
>>> between 64bit math and 80bit math is whether a MBDA Meteor missile
>>> will hit its target or not (Michael Östergren holds a personal grudge
>>> against valgrind because of weeks lost due this particular
>>> embarrassing bug screwing up simulations btw), whether the beams in
>>> LHC will meet the (intended!) target or not, whether math in SAS
>>> software works or not (warranting a warning in the written
>>> documentation that running with valgrind to test 3rd party plugins is
>>> not supported). So the list of things which do *NOT* work with
>>> valgrind is *impressive* and hurt high value projects, IMHO warranting
>>> at least the removal of that mocking comment "...Whether or not this
>>> is critical remains to be seen...". Please.
>> Effectively, it looks clear that many applications have problems
>> with this aspect. Would be better to rephrase the doc :).
>>
>> Now, maybe these applications should better be compilable
>> with 64 bits floats, and would/should then work properly natively
>> and under valgrind.
>>
>> The gcc documentation says for -mfpmath=sse:
>>
>>   The resulting code should be considerably faster in the majority of
>>   cases and avoid the numerical instability problems of 387 code, but
>>   may break some existing code that expects temporaries to be 80
>>   bits.
>>
>> So, you might try to compile your app with the above flag
>> (I guess you might need a #ifdef or so to have a typedef that
>> is 80 bits without the above, and 64 bits with the above).
>>
>> But of course, we all agree it would be nice to have 80 bits floats
>> properly supported by Valgrind. It is just nobody has time/money/effort
>> to spend on that :(.
>
> Kickstarter project maybe?

Philippe?


>
> Tina
> --
> Tina Harriott  - Women in Mathematics
> Contact: tin...@gm...

Lionel