From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109085 invoked by alias); 20 Mar 2017 21:12:17 -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 108560 invoked by uid 89); 20 Mar 2017 21:12:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=deals X-HELO: mail-oi0-f42.google.com Received: from mail-oi0-f42.google.com (HELO mail-oi0-f42.google.com) (209.85.218.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Mar 2017 21:12:15 +0000 Received: by mail-oi0-f42.google.com with SMTP id w81so28605487oig.1 for ; Mon, 20 Mar 2017 14:12:16 -0700 (PDT) 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=yc7SqhIhXfcHXlx/vuWDCR/dA4FQzRv24HofpUJnQe4=; b=VD0UTT8+Se4QrKYn4Fg0mbrwvCnQqdInIHtTFIDLig7XCvKc1eMslKoijHxxxKPYxF xheAE7HDXk3sDEPYzQzHJLQBmt8lkiS1+eXNEbOPO2ZGUL16/XXVEVppRDAGPCCSRGMb 5x6jlO5Rqpwxfkqpq9/lg1HbWQEraizt/sbOs87tT7mlrJfm8X24tzCttCJ2dhTKcdJa H3tq/WtjRO9r9OmN9v7rTu3KovdG6208JBCADvZfTcPXEsfCa/S0skXuYdxum1hZGOxU hTVrjrQ3vD/5m2mk13iRgMWO5uo/li1mIDWF/8rcuI20F6o1igWOFja4Iwtb/rhWlKgN /Jnw== X-Gm-Message-State: AFeK/H2BmeHm854d9Tn6NiydsP+ltPta0iR4Y7umIPxkwDx8P1oEnDMjR6ZdvRG/WHooR9eMvQpIPN0D8X+1CWbY X-Received: by 10.202.83.5 with SMTP id h5mr14255882oib.19.1490044335329; Mon, 20 Mar 2017 14:12:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Mon, 20 Mar 2017 14:11:54 -0700 (PDT) In-Reply-To: References: <28dd4f25-b208-52af-af1e-7bc5e36db557@gmail.com> <2c85e43f-d1dc-a74e-4d5b-c00fca8588d3@redhat.com> <066019c5-c85e-8d26-102e-aeba34988416@gmail.com> <0a4c97ac-fe30-2e3e-6694-9a3f9dbdf90c@gmail.com> <00eb2a46-a8e8-7744-a093-7eaad8c42e36@gmail.com> From: Jason Merrill Date: Mon, 20 Mar 2017 21:12: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-03/txt/msg01054.txt.bz2 On Thu, Feb 23, 2017 at 6:33 PM, Jason Merrill wrote: > On Thu, Feb 23, 2017 at 12:56 PM, Martin Sebor wrote: >> On 02/22/2017 05:43 PM, Jason Merrill wrote: >>> On Wed, Feb 22, 2017 at 3:44 PM, Martin Sebor wrote: >>>> On 02/22/2017 11:02 AM, Jason Merrill wrote: > >>>> The TREE_USED bit on the type (i.e., on >>>> TREE_TYPE(decl) where decl is the u in the test case above) is >>>> set when the function template is instantiated, in >>>> set_underlying_type called from tsubst_decl. >>> >>> Aha! That seems like the problem. Does removing that copy of >>> TREE_USED from the decl to the type break anything? >> >> As far as I can see it breaks just gcc.dg/unused-3.c which is: >> >> typedef short unused_type __attribute__ ((unused)); >> >> void f (void) >> { >> unused_type y; >> } > > Ah. So the problem here is that we're using TREE_USED on a TYPE_DECL > for two things: to track whether the typedef has been used, and to > determine whether to treat a variable of that type as already used. > Normally this isn't too much of a problem because we copy the > TREE_USED flag from decl to type before there could be any uses, but > in a template I guess we mark the typedef within the template when it > is used, and then when we instantiate the typedef we incorrectly pass > that mark along to the type. > > Your patch deals with this by ignoring TREE_USED on the type, so it > doesn't matter that it's wrong. Another approach would be to correct > the setting of TREE_USED by setting it based on looking up the unused > attribute, rather than copying it from the TYPE_DECL. So also going > back to the attribute, but in set_underlying_type rather than > poplevel. Thoughts? Jason