> 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.] In some respects memcheck of FP code is a schema operation where the width of FP is an independent variable. If you can force the code to execute the same path, then the width of FP does not matter to the memcheck results. It may be possible to evade the width issue by melding a code coverage analysis with the output of memcheck on the code for 'double'. -- ------------------------------------------------------------------------------ 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
