I ran across a case where valgrind reported an undefined value that I was sure was a false positive, but after investigating more closely, it appears valgrind was simply propagating the validity of an actual undefined value to the wrong place. Trying to decide why, I looked at the current source code, and as far as I can tell, valgrind does not properly handle definedness bits in the case of dependency-breaking operations. For example:
xor %ecx,%ecx should leave all of the bits of %ecx defined, regardless of whether they were defined before or not. However, in mc_translate.c, one finds that Iop_Xor32 is always reduced to mkUifU32, with no check that I can find if the arguments are the same. It would obviously be extremely expensive to track if two values are provably the same (mov %ecx,%edx; xor %ecx,%edx), but one should at the very least be able to handle the case where the arguments are in the same location. This also includes operations such as pxor, sub, psub, and pcmpeq (in all their various sizes). It was pcmpeq that appears to have triggered the false positive in my case. Am I on crack? I'm not familiar with the codebase, so I could easily have missed something. Should I file a bug report? ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
