Hi John, >> Due to that precision loss, I cannot further use valgrind. Some numeric >> integals etc. heavily depend on numeric precision... > > [This response is general and somewhat theoretical, but might aid > in understanding some big-picture aspects of memcheck and FP.] > > What is the expected benefit from a valgrind that handles FP that is > wider than 'double'? Memcheck handles uninit FP very simply: if any input > bit to an FP operation is uninit, then all output bits are uninit. > There is no bit-by-bit analysis for an FP op like there is for [most] > integer operations. [Integer divide and remainder are not handled as > precisely by memcheck as integer addition, subtraction, and boolean ops. > There are some cryptography apps where this matters.]
the problem I have is that due to extra rounding when running under valgrind, eventually the program behaves differently, different code paths are taken, etc, which can make valgrind useless for trying to debug some failures, because the failure doesn't occur under valgrind. This has nothing to do with tracking uninitialized bits etc in floating point numbers. In fact if valgrind ignored floating point numbers and just executed them natively that would be fine with me. Ciao, Duncan. ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
