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 202E33858C27 for ; Mon, 14 Feb 2022 17:37:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 202E33858C27 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 38A2A3039B04; Mon, 14 Feb 2022 18:37:26 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id E97ED425A478; Mon, 14 Feb 2022 18:37:25 +0100 (CET) Message-ID: <3bfbfbf02e2d17d45b4a91e5ea5f855e0a62e5f5.camel@klomp.org> Subject: Re: Uninit warnings due to optimizing short-circuit conditionals From: Mark Wielaard To: David Malcolm , gcc@gcc.gnu.org Cc: Julian Seward Date: Mon, 14 Feb 2022 18:37:25 +0100 In-Reply-To: References: <20220214155757.861877-1-dmalcolm@redhat.com> <71de3204e639eed5052ca9e6416334aba6b2d1c7.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=-3.8 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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: Mon, 14 Feb 2022 17:37:30 -0000 On Mon, 2022-02-14 at 12:20 -0500, David Malcolm wrote: > On Mon, 2022-02-14 at 17:57 +0100, Mark Wielaard wrote: > > On Mon, 2022-02-14 at 10:57 -0500, David Malcolm wrote: > > > [CCing Mark in the hopes of insight from the valgrind side of > > > things] > >=20 > > Adding Julian to CC so he can correct me if I say something silly. > >=20 > > > There is a false positive from -Wanalyzer-use-of-uninitialized- > > > value on > > > gcc.dg/analyzer/pr102692.c here: > > >=20 > > > =E2=80=98fix_overlays_before=E2=80=99: events 1-3 > > > | > > > | 75 | while (tail > > > | | ~~~~ > > > | 76 | && (tem =3D make_lisp_ptr (tail, 5), > > > | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > | | | > > > | | (1) following =E2=80=98false=E2=80=99 branch (w= hen =E2=80=98tail=E2=80=99 is > > > NULL)... > > > | 77 | (end =3D marker_position (XOVERLAY (tem)- > > > > end)) >=3D pos)) > > >=20 > > > | | =20 > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > |...... > > > | 82 | if (!tail || end < prev || !tail->next) > > > | | ~~~~~ ~~~~~~~~~~ > > > | | | | > > > | | | (3) use of uninitialized value > > > =E2=80=98end=E2=80=99 here > > > | | (2) ...to here > > > | > > >=20 > > > The issue is that inner || of the conditionals have been folded > > > within the > > > frontend from a chain of control flow: > > >=20 > > > 5 =E2=94=82 if (tail =3D=3D 0B) goto ; else goto ; > > > 6 =E2=94=82 : > > > 7 =E2=94=82 if (end < prev) goto ; else goto ; > > > 8 =E2=94=82 : > > > 9 =E2=94=82 _1 =3D tail->next; > > > 10 =E2=94=82 if (_1 =3D=3D 0B) goto ; else goto ; > > > 11 =E2=94=82 : > > >=20 > > > to an OR expr (and then to a bitwise-or by the gimplifier): > > >=20 > > > 5 =E2=94=82 _1 =3D tail =3D=3D 0B; > > > 6 =E2=94=82 _2 =3D end < prev; > > > 7 =E2=94=82 _3 =3D _1 | _2; > > > 8 =E2=94=82 if (_3 !=3D 0) goto ; else goto ; > > > 9 =E2=94=82 : > > > 10 =E2=94=82 _4 =3D tail->next; > > > 11 =E2=94=82 if (_4 =3D=3D 0B) goto ; else goto ; > > >=20 > > > This happens for sufficiently simple conditionals in > > > fold_truth_andor. > > > In particular, the (end < prev) is short-circuited without > > > optimization, > > > but is evaluated with optimization, leading to the false positive. > > >=20 > > > Given how early this folding occurs, it seems the simplest fix is > > > to > > > try to detect places where this optimization appears to have > > > happened, > > > and suppress uninit warnings within the statement that would have > > > been short-circuited (and thus e.g. ignoring them when evaluating > > > _2 > > > above for the case where _1 is known to be true at the (_1 | _2) , > > > and > > > thus _2 being redundant). > > >=20 > > > Attached is a patch that implements this. > > >=20 > > > There are some more details in the patch, but I'm wondering if this > > > is a > > > known problem, and how e.g. valgrind copes with such code. My > > > patch > > > feels like something of a hack, but I'm not sure of any other way > > > around > > > it given that the conditional is folded directly within the > > > frontend. > >=20 > > As far as I know this is what valgrind memcheck also does with an > > bitwise or. It knows that _3 is defined and true if either _1 or _2 > > is > > defined and true. Or more generically that the result bits of a > > bitwise > > or are defined for those bits that are both defined or where one is > > defined and has the value 1. >=20 > Aha - thanks. I think the distinction here is that: >=20 > * GCC's -fanalyzer complains about uninitialized values immediately > when it sees one being fetched for use in any expression (replacing the > value with a safe one to avoid further complaints), without considering > how they are going to be used in the expression, whereas >=20 > * it sounds like valgrind keeps track of uninitialized bits, propagates > the "uninit-ness" of the bits, and complains at certain times when > uninitialized bits are used in certain ways. 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 Cheers, Mark