|
From: <vms...@sn...> - 2009-11-08 00:39:28
|
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? |
|
From: Julian S. <js...@ac...> - 2009-11-08 11:15:53
|
On Sunday 08 November 2009, vms...@sn... wrote: > I ran across a case where valgrind reported an undefined value that I > was sure was a false positive, but after investigating more closely, If you have a standalone test program with pcmpeq which shows a false positive, I'd be certainly be interested to see it. Considerable effort has been expended over the years in order to get rid of false positives, I'm always on the lookout for cases that were missed. > 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's true that Memcheck doesn't check for identical args to Iop_Xor32. That's because it relies on the compilation pipeline ahead of it to clean such cases up. > Should I file a bug report? Yes, please do. J |
|
From: <vms...@sn...> - 2009-11-08 16:01:20
|
Julian Seward jseward-at-acm.org |valgrind-users| wrote: > It's true that Memcheck doesn't check for identical args to Iop_Xor32. > That's because it relies on the compilation pipeline ahead of it to > clean such cases up. Ah-hah. I was sure I had missed something. It seems like something that would have occurred far too often in practice to have been missed up until now. I was able to construct a simple test case for pcmpeq, but I can confirm that substituting in xor instead does not trigger the problem. >> Should I file a bug report? > > Yes, please do. http://bugs.kde.org/show_bug.cgi?id=213685 |