From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119050 invoked by alias); 21 Feb 2017 20:33:07 -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 118081 invoked by uid 89); 21 Feb 2017 20:33:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=sk:msebor@, mseborgmailcom, sk:msebor, msebor@gmail.com X-HELO: mail-ot0-f174.google.com Received: from mail-ot0-f174.google.com (HELO mail-ot0-f174.google.com) (74.125.82.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Feb 2017 20:33:05 +0000 Received: by mail-ot0-f174.google.com with SMTP id w44so34185918otw.2 for ; Tue, 21 Feb 2017 12:33:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MMcAM/2FQIviwRh7Syv7uCTFeKUH4/z3722wmGx2N98=; b=XXMR+a+4DFmwyzOxUbxeqettxjIqaWnwI05GVB3HZ+09GQSi0uWt51R34pzYAvFb1G LbhEG8YS4p/IimrMFrRSAoCK8JNX41DKqcD8GoRO3AXdNDWn+JQ2SOISw372cTf9RDpz 9u89ZJlwsINyizy5lb9pgmvje95Oj0VNx42faHbL2vQ9KbGgR8lt7n3aJl/e2ErjJo3s I9Hki/KlO0JPns0HwbYr7Uc5Sm3LMOEqRQsjCSC6Hfr9udP3PN17Fb5FiUq81yoLpyTV bEDSKjf7i8nK1Q5qBpbRChCeOyV+cLqRKItuUpjsqSRMF/nN2eVMC64K5yWzZ5pe7ao3 DEWw== X-Gm-Message-State: AMke39mbl0XXHbxsVsTRHU3Nyxts6YYDXtib7pnx+thmfnexnEP3hzXDYZTNRG/GzRbpXKy4BsiWZ7zkW/vcAAAV X-Received: by 10.157.1.105 with SMTP id 96mr8812848otu.33.1487709184297; Tue, 21 Feb 2017 12:33:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.5.4 with HTTP; Tue, 21 Feb 2017 12:32:43 -0800 (PST) In-Reply-To: <066019c5-c85e-8d26-102e-aeba34988416@gmail.com> References: <28dd4f25-b208-52af-af1e-7bc5e36db557@gmail.com> <2c85e43f-d1dc-a74e-4d5b-c00fca8588d3@redhat.com> <066019c5-c85e-8d26-102e-aeba34988416@gmail.com> From: Jason Merrill Date: Tue, 21 Feb 2017 20:35:00 -0000 Message-ID: Subject: Re: [PATCH] restore -Wunused-variable on a typedef'd variable in a function template (PR 79548) To: Martin Sebor Cc: Gcc Patch List Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg01348.txt.bz2 On Tue, Feb 21, 2017 at 11:00 AM, Martin Sebor wrote: > On 02/21/2017 11:08 AM, Jason Merrill wrote: >> >> On 02/17/2017 05:07 PM, Martin Sebor wrote: >>> >>> * decl.c (poplevel): Avoid diagnosing entities declared with >>> attribute unused. >> >> >> This change is OK. >> >>> (initialize_local_var): Do not consider the type of a variable >>> when determining whether or not it's used. >> >> >> This is not; the documentation for attribute unused says, >> >> When attached to a type (including a @code{union} or a @code{struct}), >> this attribute means that variables of that type are meant to appear >> possibly unused. GCC does not produce a warning for any variables of >> that type, even if the variable appears to do nothing. This is often >> the case with lock or thread classes, which are usually defined and then >> not referenced, but contain constructors and destructors that have >> nontrivial bookkeeping functions. >> >> So a TREE_USED type should imply TREE_USED on variables of that type. > > Yes, I'm familiar with the effect of the attribute on types but > in my testing this change doesn't affect how it works (i.e., it > passes a full bootstrap and regression tests and I haven't been > able to construct a failing test case.) It looks like that's > because TREE_USED(decl) is already set here for a decl whose > type is declared attribute used. > > While trying to come up with a test case to exercise the scenario > you describe I see that current trunk doesn't handle it correctly > but the patch just happens to fix that too. For example: > > template > void f () > { > T t; // trunk warns for f (good) > > typedef T U; > U u; // trunk doesn't warn for f (bug 79548) > } > > template void f(); > > struct __attribute__ ((unused)) S { }; > > template void f(); // no warnings here (good) > > void g () > { > S s; > > typedef S T; > T t; // trunk warns here (new bug), doesn't with the patch > } > > In the test case above, TREE_USED (TREE_TYPE (decl)) is set for > t in g() so trunk sets it on t too and warbs. The patch doesn't > and so it doesn't warn as expected. > > But it's entirely possible I'm missing a case. Do you have > a suggestion for a test that trunk handles correctly but that > fails with the patch? Ah, I see, your patch changes attribute unused handling for local variables from tracking TREE_USED to lookup_attribute. I'm not opposed to this change, but I'd like to understand why the TREE_USED handling wasn't working. Jason