From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92241 invoked by alias); 3 Sep 2019 20:27:36 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 92200 invoked by uid 89); 3 Sep 2019 20:27:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-14.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Sep 2019 20:27:32 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 791DE18C893C; Tue, 3 Sep 2019 20:27:31 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-3.rdu2.redhat.com [10.10.112.3]) by smtp.corp.redhat.com (Postfix) with ESMTP id 33F8A5DAAD; Tue, 3 Sep 2019 20:27:29 +0000 (UTC) Subject: Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization To: Jakub Jelinek , JiangNing OS , Martin Sebor Cc: "gcc-patches@gcc.gnu.org" References: <20190729155032.GC15878@tucnak> From: Jeff Law Openpgp: preference=signencrypt Message-ID: Date: Tue, 03 Sep 2019 20:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190729155032.GC15878@tucnak> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00156.txt.bz2 On 7/29/19 9:50 AM, Jakub Jelinek wrote: > On Tue, Jul 23, 2019 at 04:26:24AM +0000, JiangNing OS wrote: >> --- a/gcc/ChangeLog >> +++ b/gcc/ChangeLog >> @@ -1,3 +1,9 @@ >> +2019-07-22 Jiangning Liu >> + >> + PR middle-end/91195 >> + * tree-ssa-phiopt.c (cond_store_replacement): Work around >> + -Wmaybe-uninitialized warning. >> + >> 2019-07-22 Stafford Horne >> >> * config/or1k/or1k.c (or1k_expand_compare): Check for int before >> diff --git a/gcc/tree-ssa-phiopt.c b/gcc/tree-ssa-phiopt.c >> index b64bde695f4..7a86007d087 100644 >> --- a/gcc/tree-ssa-phiopt.c >> +++ b/gcc/tree-ssa-phiopt.c >> @@ -2240,6 +2240,14 @@ cond_store_replacement (basic_block middle_bb, basic_block join_bb, >> tree base = get_base_address (lhs); >> if (!auto_var_p (base) || TREE_ADDRESSABLE (base)) >> return false; >> + >> + /* The transformation below will inherently introduce a memory load, >> + for which LHS may not be initialized yet if it is not in NOTRAP, >> + so a -Wmaybe-uninitialized warning message could be triggered. >> + Since it's a bit hard to have a very accurate uninitialization >> + analysis to memory reference, we disable the warning here to avoid >> + confusion. */ >> + TREE_NO_WARNING (lhs) = 1; > > I don't like this, but not for the reasons Martin stated, we use > TREE_NO_WARNING not just when we've emitted warnings, but in many places > when we've done something that might trigger false positives. > Yes, it would be nice to do it more selectively. > > The problem I see with the above though is that lhs might very well be > a decl, and setting TREE_NO_WARNING on it then doesn't affect only the > hoisted load, but also all other code that refers to the decl. LHS is restricted to just MEM_REF, ARRAY_REF and COMPONENT_REF. We'd be setting the NO_WARNING bits on the toplevel expression, but not on anything shared like a _DECL node. So what we're losing here would be things like out of bounds array checks on the LHS, so it still sucks. > > If the TREE_NO_WARNING bit is set on something that isn't shareable, that is > fine with me, like a MEM_REF, TARGET_MEM_REF or handled component. If lhs > is a decl, can we force a MEM_REF around it (and won't we fold it back to > the decl?)? Or perhaps better, can we gimple_set_no_warning on the load > stmt instead? We have the toplevel statement, so that might be worth a try as well. jeff