Re: Uninit warnings due to optimizing short-circuit conditionals

[Mark Wielaard <mark@klomp.org>]

Hi Richard,

On Tue, 2022-02-15 at 08:25 +0100, Richard Biener wrote:
> On Mon, Feb 14, 2022 at 6:38 PM Mark Wielaard <mark@klomp.org> wrote:
> > Yes. valgrind keeps track of uninitialized bits and propagates them
> > around till "use". Where use is anything that might alter the
> > observable behavior of the program. Which is control flow
> > transfers, conditional moves, addresses used in memory accesses,
> > and data passed to system calls.
> > 
> > This paper describes some of the memcheck tricks:
> > https://valgrind.org/docs/memcheck2005.pdf
> 
> That probably means bugs like 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311
> could be resolved as fixed (in valgrind).

I just tried the testcase from that bug and it still replicates with
gcc 11.2.1 and valgrind 3.18.1. And as far as I can see it really
cannot be fixed in valgrind since gcc really generates a conditional
jump based on an uninit variable in this case.

It does look a bit like what Julian described in:

  Memcheck Reloaded
  dealing with compiler-generated branches on undefined values
https://archive.fosdem.org/2020/schedule/event/debugging_memcheck_reloaded/

Which should be able to recover/reconstruct the original control flow.
In cases like:

int result
bool ok = compute_something(&result)
if (ok && result == 42) { ... }

where gcc turns that last line upside down:

if (result == 42 && ok) { ... }

But it doesn't work in this case. Probably because this is a slightly
more complex case involving 3 distinct variables instead of 2.

Cheers,

Mark