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 <m...@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
