From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2B4FF385DC2D for ; Tue, 10 May 2022 13:54:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B4FF385DC2D Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-554-rdXEmx2rPiab0y9xqo9QDw-1; Tue, 10 May 2022 09:54:15 -0400 X-MC-Unique: rdXEmx2rPiab0y9xqo9QDw-1 Received: by mail-qt1-f197.google.com with SMTP id i11-20020ac85e4b000000b002f3d8c3a96dso5396926qtx.9 for ; Tue, 10 May 2022 06:54:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=cIrxaCmc7du1EpJqYxqcfeUzOiyyNMJyfe0fgZJWHt0=; b=yCwP+hYRIilYZY2TXGtY8MG+vbKgyxIkSnS1KtYzohUwMIQPfc8KIjTmh6WZhT/jc+ UvpbCh0d2hvJFy+dK8XLdxNmfynufxz61z/OmLuxsyH5QsEEiluWvCdB5L5MDKdJdRjE iN3ne30/1Tm/XHMTTM/sQiXl8sCtcHs7avZV14AUSA9QEB8hUeZxn9wYfZDGrJ722mv/ t9u48H5vr3TOpXR+cM0q2dsk0JBUlqBNDvtXP8XJqRjDF21dwaCj2ISerHZpAhPiHcI6 l4HeARWjqCx/DBM2CIHSeHEZAFfgyF9QHxb1C7gncGMYCuZBv6/BfeGuapSwf/dnycxf VkLw== X-Gm-Message-State: AOAM5317DGryviH+/jP0CH7V2P/rjMjRb2WtOQTIroVRHV14LFfz5ddk Y15Akb5j8nwKZXTR2coDTF7EaSgfehBp22bKdtOc61dPEp3GdpG8WXFVsGTdDKXImOxn45EwrT3 OL+Uk2vToSbdVICc8IQ== X-Received: by 2002:ad4:5de5:0:b0:45b:53b:6824 with SMTP id jn5-20020ad45de5000000b0045b053b6824mr10292044qvb.75.1652190855324; Tue, 10 May 2022 06:54:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+/AM/ZIZ/0O/2y07oVf/fWg6wk1bqPHAonzs5k9eqLuzvVYFSatmHDgbXSf/NN30kETAV+A== X-Received: by 2002:ad4:5de5:0:b0:45b:53b:6824 with SMTP id jn5-20020ad45de5000000b0045b053b6824mr10292034qvb.75.1652190855125; Tue, 10 May 2022 06:54:15 -0700 (PDT) Received: from redhat.com ([2601:184:4780:4310::e811]) by smtp.gmail.com with ESMTPSA id y7-20020ac87c87000000b002f39b99f67csm9464819qtv.22.2022.05.10.06.54.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 May 2022 06:54:14 -0700 (PDT) Date: Tue, 10 May 2022 09:54:12 -0400 From: Marek Polacek To: Jason Merrill Cc: GCC Patches , Joseph Myers Subject: Re: [PATCH v2] c, c++: -Wswitch warning on [[maybe_unused]] enumerator [PR105497] Message-ID: References: <20220507221456.552767-1-polacek@redhat.com> <580b12c2-fa83-d268-373d-64bee758bf85@redhat.com> MIME-Version: 1.0 In-Reply-To: <580b12c2-fa83-d268-373d-64bee758bf85@redhat.com> User-Agent: Mutt/2.1.5 (2021-12-30) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2022 13:54:18 -0000 On Tue, May 10, 2022 at 08:58:46AM -0400, Jason Merrill wrote: > On 5/7/22 18:26, Marek Polacek wrote: > > Corrected version that avoids an uninitialized warning: > > > > This PR complains that we emit the "enumeration value not handled in > > switch" warning even though the enumerator was marked with the > > [[maybe_unused]] attribute. > > > > The first snag was that I couldn't just check TREE_USED, because > > the enumerator could have been used earlier in the function, which > > doesn't play well with the c_do_switch_warnings warning. Instead, > > I had to check the attributes on the CONST_DECL directly, which led > > to the second, and worse, snag: in C we don't have direct access to > > the CONST_DECL for the enumerator. > > I wonder if you want to change that instead of working around it? I wouldn't mind looking into that; I've hit this discrepancy numerous times throughout the years and it'd be good to unify it so that the c-common code doesn't need to hack around it. Let's see how far I'll get... > > + const bool unused_p = (lookup_attribute ("unused", attrs) > > + || lookup_attribute ("maybe_unused", attrs)); > > Why is this calculation... > > > node = splay_tree_lookup (cases, (splay_tree_key) value); > > if (node) > > { > > @@ -1769,6 +1784,10 @@ c_do_switch_warnings (splay_tree cases, location_t switch_location, > > /* We've now determined that this enumerated literal isn't > > handled by the case labels of the switch statement. */ > > + /* Don't warn if the enumerator was marked as unused. */ > > + if (unused_p) > > + continue; > > ...separate from this test? Ah, that must be a remnant from a previous version of the patch. No reason for the separation anymore. Thanks, Marek