From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26724 invoked by alias); 29 Jun 2017 18:20:03 -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 26680 invoked by uid 89); 29 Jun 2017 18:20:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=guiding, friends, HContent-Transfer-Encoding:8bit 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; Thu, 29 Jun 2017 18:20:00 +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 3D30D31E7B7; Thu, 29 Jun 2017 18:19:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3D30D31E7B7 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 3D30D31E7B7 Received: from localhost.localdomain (ovpn-117-103.phx2.redhat.com [10.3.117.103]) by smtp.corp.redhat.com (Postfix) with ESMTP id 00F3F17CF7; Thu, 29 Jun 2017 18:19:58 +0000 (UTC) Subject: Re: PR80806 To: Prathamesh Kulkarni , gcc Patches , Richard Biener References: From: Jeff Law Message-ID: Date: Thu, 29 Jun 2017 18:20:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg02317.txt.bz2 On 05/18/2017 12:55 PM, Prathamesh Kulkarni wrote: > Hi, > The attached patch tries to fix PR80806 by warning when a variable is > set using memset (and friends) but not used. I chose to warn in dse > pass since dse would detect if the variable passed as 1st argument is > a dead store. Does this approach look OK ? [ ... ] So I think the biggest question is whether or not the case like Martin's deserves a warning. What we have is an object that is conditionally set but not used depending on inlining context. We've generally "allowed" inlining to expose new warnings in the sense that inlining may (for example) allow us to remove the addressibility property on an object -- which makes the object subject to the usual -Wuninitialized analysis. In fact, I think we've generally considered that a positive outcome because it's exposing bugs in subtle paths. I'm less sure that this case falls into that same category. What we're really talking about is warning for a partially dead store. Would we want a warning if rather than a memset this was a simple store? Is that the right guiding principle here? I hate to say it, but I wonder if this is another case where there likely won't be a clear consensus and we're going to end up with a two level warning system? For something like Martin's case what I really think we should do is sink the memset call into the conditional. In cases where "i" is not a constant, but actually has the value zero at runtime we win. -- So I've got no objections to the idea of using DSE to detect the dead store and potentially warn. My concern is are we in a case where that warning is going to annoy users and we end up needing a level of -Wunused-but-set. Jeff