From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 93C673858434 for ; Tue, 15 Feb 2022 12:29:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 93C673858434 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 77A4C3039B04; Tue, 15 Feb 2022 13:29:25 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id C9D84403F6F5; Tue, 15 Feb 2022 13:29:24 +0100 (CET) Message-ID: Subject: Re: Uninit warnings due to optimizing short-circuit conditionals From: Mark Wielaard To: Richard Biener Cc: David Malcolm , GCC Development , Julian Seward Date: Tue, 15 Feb 2022 13:29:24 +0100 In-Reply-To: References: <20220214155757.861877-1-dmalcolm@redhat.com> <71de3204e639eed5052ca9e6416334aba6b2d1c7.camel@klomp.org> <3bfbfbf02e2d17d45b4a91e5ea5f855e0a62e5f5.camel@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2022 12:29:31 -0000 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 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. > >=20 > > This paper describes some of the memcheck tricks: > > https://valgrind.org/docs/memcheck2005.pdf >=20 > That probably means bugs like=20 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D63311 > 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 =3D compute_something(&result) if (ok && result =3D=3D 42) { ... } where gcc turns that last line upside down: if (result =3D=3D 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