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 9D6833858C27 for ; Mon, 14 Feb 2022 16:57:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9D6833858C27 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 781D830003AC; Mon, 14 Feb 2022 17:57:13 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id A99D9425A478; Mon, 14 Feb 2022 17:57:12 +0100 (CET) Message-ID: <71de3204e639eed5052ca9e6416334aba6b2d1c7.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 17:57:12 +0100 In-Reply-To: <20220214155757.861877-1-dmalcolm@redhat.com> References: <20220214155757.861877-1-dmalcolm@redhat.com> 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 16:57:17 -0000 Hi David, 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] Adding Julian to CC so he can correct me if I say something silly. > 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 (when = =E2=80=98tail=E2=80=99 is NULL)... > | 77 | (end =3D marker_position (XOVERLAY (tem)->end))= >=3D pos)) > | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~ > |...... > | 82 | if (!tail || end < prev || !tail->next) > | | ~~~~~ ~~~~~~~~~~ > | | | | > | | | (3) use of uninitialized value =E2=80=98e= nd=E2=80=99 here > | | (2) ...to here > | >=20 > The issue is that inner || of the conditionals have been folded within th= e > 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. 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. Cheers, Mark