From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by sourceware.org (Postfix) with ESMTPS id 781843858D20 for ; Mon, 14 Feb 2022 16:26:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 781843858D20 Received: by mail-pj1-x102b.google.com with SMTP id r64-20020a17090a43c600b001b8854e682eso16383200pjg.0 for ; Mon, 14 Feb 2022 08:26:28 -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:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=+Ajp7vh29Q6Is2DaRoANiWqEJYQj2XzFnOaAztDqX08=; b=V/jkOk+NBIxtgEHe8YQbXq92BylRyt2AMzX6OESUrFfVtokCe6BgaMZ8XTv2wbsgfO mhHGWIp+qXMnZmodNHTA+gFS3drWj6JCzs2T/LG7vZCur/KWfY0CGqLjEDHTj1GL+3by ZhHCNZi4SNyquKdtLvxVIEtYRPemDiZev6Z90eVhLdDbR4IMs2ebwmkgbe7P3mGphqYj 4YPQVyLlAqKgJ3aYFeYHPR6CXWyJy/2iUer7L3983SWsczRfAxWaBf58VI9SDVxVjvnH RUBl/vzh5T89xIA2+WGFMq4pcqhegBVxZ6kuom0vpKrGgk5mEIuFYeJH8LMuXaO2vhzB vD3Q== X-Gm-Message-State: AOAM5325E1JL144ACrSDeRT/O967XcrqJxqnDqcD34RvvD1mt/9CUluQ zBYK/TzyTtNneS3W8gBmd78= X-Google-Smtp-Source: ABdhPJzSiGkj0yN/B6NJpZQP2CPXVegIr0W1AFeJjnFYU4M2WiUYvoXM980LiQEJ/2GLVaMN9kLi5g== X-Received: by 2002:a17:902:d2c2:: with SMTP id n2mr428147plc.5.1644855987313; Mon, 14 Feb 2022 08:26:27 -0800 (PST) Received: from [172.31.0.204] (c-73-63-24-84.hsd1.ut.comcast.net. [73.63.24.84]) by smtp.gmail.com with ESMTPSA id qe7sm5953816pjb.25.2022.02.14.08.26.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Feb 2022 08:26:26 -0800 (PST) Message-ID: <601e7f97-bd52-bc66-7a1a-c26c18c5a794@gmail.com> Date: Mon, 14 Feb 2022 09:26:25 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: Uninit warnings due to optimizing short-circuit conditionals Content-Language: en-US To: David Malcolm , gcc@gcc.gnu.org Cc: Mark Wielaard References: <20220214155757.861877-1-dmalcolm@redhat.com> From: Jeff Law In-Reply-To: <20220214155757.861877-1-dmalcolm@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, 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: Mon, 14 Feb 2022 16:26:30 -0000 On 2/14/2022 8:57 AM, David Malcolm via Gcc wrote: > [CCing Mark in the hopes of insight from the valgrind side of things] > > 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. Presumably when "tail ==0", "end" is initialized somewhere?  If so, yes, this is a known issue.  There's a BZ about it somewhere (I don' t have the # handy, but it's probably on the Wuninitialized tracker). Jeff