From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 46AE33858C27 for ; Mon, 14 Feb 2022 17:20:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 46AE33858C27 Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-638-RyO4xgidOauVsk7xc6uB3A-1; Mon, 14 Feb 2022 12:20:17 -0500 X-MC-Unique: RyO4xgidOauVsk7xc6uB3A-1 Received: by mail-qk1-f200.google.com with SMTP id g3-20020a05620a108300b0047e16fc0d6cso9590369qkk.3 for ; Mon, 14 Feb 2022 09:20:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=ZcFvlg+HgqYjgkm6FXye66JRkQOocAIrINQRvysDhKk=; b=Vz2/Zzu22jbFrucCDFkYgeHt6cam0aQKa+Z0Wlu/MPDzaFjBN00Kq3ojPiMsW4jZER qIqaZAPLXhviWzNgrWKbSjC5J04mumXrvm1V5nN1MutqbxheoVPJIFWrkUKdX09Jywre ROa6opKPzjqm0a9M5gcpEAp5Gm5vsy9wUEbaiOst5Pde4ja41SIEyjv6rCPl7e4u8Fd2 PnNHSHiEBDKvz5Iphwq6AxXChS917MBqfML4t6Jnm05RsQUHelmLxu2R/B6AEmYYBh3Q j8JusDnU0iKQhBqd7ashxXofgwiYSKP4XmQPmC7/hN5HOgcYVV0HSX+qFGqjGNUkfllg 1o0Q== X-Gm-Message-State: AOAM532bjCgVm4MQwJNxMvxvkEJl8oGqKCAI3/YjlSE1T/zccaS1oBpH TSSfL6jAVaIVOPy4CAQjrxXH2FS1sDfbNGbjaRrn7fvHfWNa/UMZgNf/w/x74WonHba5tI9uqW6 4EpSSVeM= X-Received: by 2002:a37:9444:: with SMTP id w65mr426117qkd.468.1644859217507; Mon, 14 Feb 2022 09:20:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJwJyTIwQVGQ42OnoCpaLAXHCNlyFZnHapzWcga3D3HpfxhmL6vJD1Q+TUs1KAmJDy6ivNnaLw== X-Received: by 2002:a37:9444:: with SMTP id w65mr426106qkd.468.1644859217248; Mon, 14 Feb 2022 09:20:17 -0800 (PST) Received: from t14s.localdomain (c-73-69-212-193.hsd1.ma.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id n6sm18025309qtx.23.2022.02.14.09.20.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Feb 2022 09:20:16 -0800 (PST) Message-ID: Subject: Re: Uninit warnings due to optimizing short-circuit conditionals From: David Malcolm To: Mark Wielaard , gcc@gcc.gnu.org Cc: Julian Seward Date: Mon, 14 Feb 2022 12:20:15 -0500 In-Reply-To: <71de3204e639eed5052ca9e6416334aba6b2d1c7.camel@klomp.org> References: <20220214155757.861877-1-dmalcolm@redhat.com> <71de3204e639eed5052ca9e6416334aba6b2d1c7.camel@klomp.org> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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: Mon, 14 Feb 2022 17:20:21 -0000 On Mon, 2022-02-14 at 17:57 +0100, Mark Wielaard wrote: > 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: > > > >   ‘fix_overlays_before’: events 1-3 > >     | > >     |   75 |   while (tail > >     |      |          ~~~~ > >     |   76 |          && (tem = make_lisp_ptr (tail, 5), > >     |      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >     |      |          | > >     |      |          (1) following ‘false’ branch (when ‘tail’ is > > NULL)... > >     |   77 |              (end = marker_position (XOVERLAY (tem)- > > >end)) >= pos)) > >     |      |              > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >     |...... > >     |   82 |   if (!tail || end < prev || !tail->next) > >     |      |       ~~~~~    ~~~~~~~~~~ > >     |      |       |            | > >     |      |       |            (3) use of uninitialized value > > ‘end’ here > >     |      |       (2) ...to here > >     | > > > > The issue is that inner || of the conditionals have been folded > > within the > > frontend from a chain of control flow: > > > >    5   │   if (tail == 0B) goto ; else goto ; > >    6   │   : > >    7   │   if (end < prev) goto ; else goto ; > >    8   │   : > >    9   │   _1 = tail->next; > >   10   │   if (_1 == 0B) goto ; else goto ; > >   11   │   : > > > > to an OR expr (and then to a bitwise-or by the gimplifier): > > > >    5   │   _1 = tail == 0B; > >    6   │   _2 = end < prev; > >    7   │   _3 = _1 | _2; > >    8   │   if (_3 != 0) goto ; else goto ; > >    9   │   : > >   10   │   _4 = tail->next; > >   11   │   if (_4 == 0B) goto ; else goto ; > > > > 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. > > > > 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). > > > > Attached is a patch that implements this. > > > > 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. Aha - thanks. I think the distinction here is that: * 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 * 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. Dave