Created attachment 89336 [details] v64.c Upcoming code produces... ==4223== Conditional jump or move depends on uninitialised value(s) ==4223== at 0x400520: main (v64.c:15) welinder@sherwood:~> gcc -Wall -O2 -g v64.c welinder@sherwood:~> ./a.out [see above] welinder@sherwood:~> valgrind --version valgrind-3.8.1 welinder@sherwood:~> gcc --version gcc (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388] Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The problem is gcc checking multiple fields at once. That seems to prevent valgrind from knowing that the first (well-defined) 8-bit test makes the rest of the test irrelevant: .LVL5: .loc 1 15 0 movabsq $-4294967041, %rdx andq (%rax), %rdx movabsq $4294967296, %rcx cmpq %rcx, %rdx je .L7
Yes. It's difficult to do anything much about that.
Well, the testcase is invalid, because it invokes undefined behavior. See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
Just to add, it is a known problem. Memcheck does have a more-expensive-and-more accurate analysis mode for 32- and 64-bit equality comparisons, but it is not enabled by default (due to expense). Instead it is enabled on a block by block basis as determined by scanning the block looking for known-problematic code (a heuristic). In this case it doesn't apply, though. You can apply it manually by finding this line in mc_translate.c mce.bogusLiterals = bogus; and changing it to mce.bogusLiterals = True; You'll take a measurable performance hit for this, though.
(In reply to Julian Seward from comment #3) > Just to add, it is a known problem. Memcheck does have a > more-expensive-and-more > accurate analysis mode for 32- and 64-bit equality comparisons, but it is > not enabled > by default (due to expense). Instead it is enabled on a block by block > basis as determined > by scanning the block looking for known-problematic code (a heuristic). In > this case > it doesn't apply, though. > > You can apply it manually by finding this line in mc_translate.c > > mce.bogusLiterals = bogus; > > and changing it to > > mce.bogusLiterals = True; > > You'll take a measurable performance hit for this, though. Yes, setting mce.bogusLiterals = True; and the complaint goes away. I'm thinking of adding --expensive-checking=yes|no default [no] to the command line as it is more convenient to use than recompiling. For the documentation of that flag it would be interesting to add what kind of performance hit has been observed in practice.
I've added a new command line option --expensive-definedness-check=yes|no in r15594.
The test cases nicely reproduces the bug (when --expensive-definedness-check=no) even on Solaris with gcc 4.8.2. Thanks for providing it!
Btw. the command line option is called '--expensive-definedness-checks' these days.
Note that there is a variant of this bug for power: https://bugs.kde.org/show_bug.cgi?id=352364