Bug 340392

Summary: Incorrect "Conditional jump..." message
Product: [Developer tools] valgrind Reporter: M Welinder <mwelinder>
Component: memcheckAssignee: Julian Seward <jseward>
Status: RESOLVED FIXED    
Severity: normal CC: flo2030, ivosh, mark, octoploid
Priority: NOR    
Version: 3.8.0   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=352364
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: v64.c

Description M Welinder 2014-10-27 12:05:51 UTC
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
Comment 1 Julian Seward 2014-10-30 14:31:51 UTC
Yes.  It's difficult to do anything much about that.
Comment 2 Markus Trippelsdorf 2014-11-03 08:55:09 UTC
Well, the testcase is invalid, because it invokes undefined behavior.
See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
Comment 3 Julian Seward 2015-08-14 09:26:22 UTC
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.
Comment 4 Florian Krohm 2015-08-14 21:14:55 UTC
(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.
Comment 5 Florian Krohm 2015-08-27 17:53:04 UTC
I've added a new command line option --expensive-definedness-check=yes|no in r15594.
Comment 6 Ivo Raisr 2015-08-28 06:02:58 UTC
The test cases nicely reproduces the bug (when --expensive-definedness-check=no) even on Solaris with gcc 4.8.2. Thanks for providing it!
Comment 7 Ivo Raisr 2017-05-05 21:37:08 UTC
Btw. the command line option is called '--expensive-definedness-checks' these days.
Comment 8 Mark Wielaard 2023-10-30 20:37:17 UTC
Note that there is a variant of this bug for power:
https://bugs.kde.org/show_bug.cgi?id=352364