On 29 January 2014 21:54, Tina Harriott <tina.harriott.m...@gmail.com> wrote: > On 22 January 2014 22:36, Philippe Waroquiers > <philippe.waroqui...@skynet.be> wrote: >> On Wed, 2014-01-22 at 00:19 +0100, Lionel Cons wrote: >>> On 22 January 2014 00:03, Tom Hughes <t...@compton.nu> 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: tina.harriott.m...@gmail.com Lionel ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
