For details see http://gcc.gnu.org/PR18089 The following testcase when compiled with recent gcc CVS or with -DUSE_ASM triggers valgrind's Conditional jump or move depends on uninitialised value(s), although it doesn't depend on unitialized bits. If subl $0x80000000, %reg is replaced with xorl $0x80000000, %reg (which appart from %eflags that are ignored anyway should have identical behaviour), the warning is not printed (correctly).
Created attachment 9099 [details] Testcase
The problem is that there are some undefined bits in %eax when subl is run, and memcheck's undefinedness-propagation algorithm ends up making all of %eax undefined. Because xor is bitwise, the undefinedness is contained, and eventually removed by the subsequent shifts. Someone (Tridge?) proposed a precise algorithm for tracking definedness, but I don't think anyone has looked at implementing it yet.
This looks similar to the constants used for the fast strlen() code, which are usually 0x80808080, I think. I think Julian may have made some progress with the accurate addition/subtraction tracking in Memcheck (it was Paul Mackerras that worked it out), in his own tree.
Memcheck does get tripped up on this kind of stuff -- we know various specific trouble cases. Recently I've completely rewritten the memcheck engine, with a result that it tracks addition, subtraction, equality comparison, floating point and SIMD integer operations much more accurately, giving a reduced false-positive rate. > ------- Additional Comments From njn25 cam ac uk 2005-01-19 04:51 ------- > This looks similar to the constants used for the fast strlen() code, which > are usually 0x80808080, I think. I think Julian may have made some > progress with the accurate addition/subtraction tracking in Memcheck (it > was Paul Mackerras that worked it out), in his own tree.
I'm closing crashing and similar bugs that are more than two years old. If you still see this problem with Valgrind 3.4.1 please reopen the bug report. Thanks.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!