|
From: Bob R. <bo...@br...> - 2013-03-04 15:33:49
Attachments:
main.adb
|
Hi, I'm using valgrind on a small Ada program (attached). The Ada program runs fine on the linux host, it prints 8.5. When I run the program through valgrind, it prints 0.0. Any ideas why this might be? I tried this with gnatmake with gnu 4.1.2 and gnu 4.2 on, $ uname -a Linux maple 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC 2010 i686 GNU/Linux Thanks, Bob |
|
From: Duncan S. <bal...@fr...> - 2013-03-04 16:00:52
|
Hi Bob, > I'm using valgrind on a small Ada program (attached). > > The Ada program runs fine on the linux host, it prints 8.5. > > When I run the program through valgrind, it prints 0.0. > > Any ideas why this might be? I tried and it works fine for me: gnatmake from gcc-4.2 and gcc-4.8, valgrind-3.9.0.SVN, on ubuntu quantal. Note that I'm on a 64 bit system (x86-64). Ciao, Duncan. > > I tried this with gnatmake with gnu 4.1.2 and gnu 4.2 on, > > $ uname -a > Linux maple 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC > 2010 i686 GNU/Linux > > Thanks, > Bob > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Philippe W. <phi...@sk...> - 2013-03-04 20:30:06
|
On Mon, 2013-03-04 at 09:39 -0500, Bob Rossi wrote: > Hi, > > I'm using valgrind on a small Ada program (attached). > > The Ada program runs fine on the linux host, it prints 8.5. > > When I run the program through valgrind, it prints 0.0. > > Any ideas why this might be? > > I tried this with gnatmake with gnu 4.1.2 and gnu 4.2 on, > > $ uname -a > Linux maple 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC > 2010 i686 GNU/Linux GNAT runtime is implementing various features (e.g. float images) by using long_long_float, which are 80 bits floats. As these are not properly supported by Valgrind, this can introduce numerical differences/errors. See e.g. https://bugs.kde.org/show_bug.cgi?id=130358 Now, I have no idea if your specific bug is caused by this. If you use a recent Valgrind version, you might debug the GNAT runtime native and under Valgrind (using gdb/vgdb) and compare the floating point behaviour between the native and the valgrind execution. (the runtime must be compiled with debug) Philippe |
|
From: Roland M. <rol...@nr...> - 2013-03-04 21:08:37
|
On Mon, Mar 4, 2013 at 9:29 PM, Philippe Waroquiers <phi...@sk...> wrote: > On Mon, 2013-03-04 at 09:39 -0500, Bob Rossi wrote: >> I'm using valgrind on a small Ada program (attached). >> >> The Ada program runs fine on the linux host, it prints 8.5. >> >> When I run the program through valgrind, it prints 0.0. >> >> Any ideas why this might be? >> >> I tried this with gnatmake with gnu 4.1.2 and gnu 4.2 on, >> >> $ uname -a >> Linux maple 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC >> 2010 i686 GNU/Linux > GNAT runtime is implementing various features (e.g. float images) > by using long_long_float, which are 80 bits floats. > As these are not properly supported by Valgrind, this can introduce > numerical differences/errors. Erm... are there any plans to fix this ? AFAIK ADA ist not the only user of |long long double| ... some parts of JDK, perl and ksh93 rely on 80biit IEEE754 math on x86 ... > See e.g. https://bugs.kde.org/show_bug.cgi?id=130358 Do you have a full list of bugs for this issue ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) rol...@nr... \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) |
|
From: Philippe W. <phi...@sk...> - 2013-03-04 21:17:26
|
On Mon, 2013-03-04 at 22:08 +0100, Roland Mainz wrote: > On Mon, Mar 4, 2013 at 9:29 PM, Philippe Waroquiers > <phi...@sk...> wrote: > > GNAT runtime is implementing various features (e.g. float images) > > by using long_long_float, which are 80 bits floats. > > As these are not properly supported by Valgrind, this can introduce > > numerical differences/errors. > > Erm... are there any plans to fix this ? AFAIK ADA ist not the only > user of |long long double| ... some parts of JDK, perl and ksh93 rely > on 80biit IEEE754 math on x86 ... No, there is no plan to fix this. See https://bugs.kde.org/show_bug.cgi?id=197915#c9 > > > See e.g. https://bugs.kde.org/show_bug.cgi?id=130358 > > Do you have a full list of bugs for this issue ? https://bugs.kde.org/show_bug.cgi?id=197915 seems track a lot of duplicate bugs. But there are probably some not yet marked as duplicate. Philippe |
|
From: Lionel C. <lio...@go...> - 2013-03-05 17:54:40
|
On 4 March 2013 22:17, Philippe Waroquiers <phi...@sk...> wrote: > On Mon, 2013-03-04 at 22:08 +0100, Roland Mainz wrote: >> On Mon, Mar 4, 2013 at 9:29 PM, Philippe Waroquiers >> <phi...@sk...> wrote: >> > GNAT runtime is implementing various features (e.g. float images) >> > by using long_long_float, which are 80 bits floats. >> > As these are not properly supported by Valgrind, this can introduce >> > numerical differences/errors. >> >> Erm... are there any plans to fix this ? AFAIK ADA ist not the only >> user of |long long double| ... some parts of JDK, perl and ksh93 rely >> on 80biit IEEE754 math on x86 ... > No, there is no plan to fix this. See > https://bugs.kde.org/show_bug.cgi?id=197915#c9 > >> >> > See e.g. https://bugs.kde.org/show_bug.cgi?id=130358 >> >> Do you have a full list of bugs for this issue ? > https://bugs.kde.org/show_bug.cgi?id=197915 > seems track a lot of duplicate bugs. > > But there are probably some not yet marked as duplicate. (1) in https://bugs.kde.org/show_bug.cgi?id=197915#c9 is a joke: >Julian Seward 2010-07-12 15:58:25 UTC > As per comment #0, adding support for 80-bit floats is low priority, because (1) AIUI the majority of floating point code is portable > and restricts itself to 64-bit values, The majority of _consumer_ software uses using double (aka 64bit float), but the majority of _scientific_ software (for example the whole NIH bioinformtics software stack or 99.9% of CERNs simulation software) is relying on long long double aka 80bit or 128bit floats (depending on platform, AMD64 uses 80bits). valgrind is useless for such software. Use Rational Purify instead - problem solved if you're professional business, there's unfortunately no alternative for the opensource community. Lionel |
|
From: Philippe W. <phi...@sk...> - 2013-03-05 22:56:40
|
On Tue, 2013-03-05 at 18:54 +0100, Lionel Cons wrote: > (1) in https://bugs.kde.org/show_bug.cgi?id=197915#c9 is a joke: > >Julian Seward 2010-07-12 15:58:25 UTC > > As per comment #0, adding support for 80-bit floats is low priority, because (1) AIUI the majority of floating point code is portable > > and restricts itself to 64-bit values, > > The majority of _consumer_ software uses using double (aka 64bit > float), but the majority of _scientific_ software (for example the > whole NIH bioinformtics software stack or 99.9% of CERNs simulation > software) is relying on long long double aka 80bit or 128bit floats > (depending on platform, AMD64 uses 80bits). valgrind is useless for > such software. I am not too sure about the proportion of consumer software versus scientific software. Assuming there is more consumer software, the note (1) above is not such a joke at the end :). Reading the gcc manual, wouldn't it be a good idea to have the scientific software to be rewritten (or at least compilable) so as to use sse ? gcc manual tells for `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 80bit. This is the default choice for the x86-64 compiler. And as a bonus, you can run it under Valgrind on x86/amd64 :). If this scientific code is fully portable, then you could also decide to run it under Valgrind e.g. on ppc32/ppc64 systems. Note: at my work, we are using Ada/gnat/gcc on x86/amd64. The application code is compiled with sse. We contemplated recompiling and/or changing the Ada runtime to use sse only and fully avoid the 80 bits. However, as at the end, we found very little impact (at least for our apps) of running the 80 bits runtime on Valgrind, we have kept the default gnat runtime (which uses 80 bits floats here and there). As long as these 80 bits computation are "ok" if computation is in reality done with 64 bits float, then not much impact. YMMV. Note that we have not got any indication that the original problem of Bob is linked to 80 bits. Duncan's trials were succesful, I also tried at work and at home, and always obtained the expected answer. Philippe |