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 ESMTP id E4B553858D39 for ; Tue, 21 Sep 2021 21:40:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E4B553858D39 Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-268-A8S_jJmyOYGhSJ6ZUj32-g-1; Tue, 21 Sep 2021 17:40:16 -0400 X-MC-Unique: A8S_jJmyOYGhSJ6ZUj32-g-1 Received: by mail-qt1-f199.google.com with SMTP id o7-20020a05622a138700b002a0e807258bso3596422qtk.13 for ; Tue, 21 Sep 2021 14:40:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=EEHdmboftxO4FQGxDigNUCUkT7uQW/iTKAAO483Uf88=; b=t3Ot92YG9f5I1a6CpU7jn+PejU3mrh7C0M4jr9UknUC5BR8F+j35k8CFOkBAbLQn9C IhROnf1pbsQsXwwktRcfM1axzDTh/Wh1AVoBReDScyo4dGyEz+EOsvyjr97lcyoktRhg d97N/LNklHkcN9A8nRBTUfTiiD6o4T+BozhRyDEiuRgdBLYBxyJ0bDR0ZUd5HtE/WXN8 AWopjU//H0yhLOGhlw9L6/q5aO4fu5AyQTxIltUUEjbOpdBnztXV34WAQNVuOcWKw/Lc Wr48Uj74zBQg4TuzAqxFI6wGRJPh5jN52KXTAOw66EeFmumAF3IxJbKX+gPRmK5JOdJ2 CxcA== X-Gm-Message-State: AOAM5333OEHQsbN2nHbtLd53IwWkNhpstVdJ1OMKuviMEJkcxgE4X5Gn ZdPRUOOwugYeC6NkXLY1pbLnhrEzGO6fbOca3jyO1oQIJBdNdzOuvQuthT3Vad9zZs4aXhJ7EN7 8tZKDx+zLQQLRtSizwQ== X-Received: by 2002:ac8:7cb:: with SMTP id m11mr31178922qth.72.1632260415943; Tue, 21 Sep 2021 14:40:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzkQMm2XDFVdrcJmGVJn0TjW9zX7Rox0Upafo6N4b5yxAHrI7IL34PfVD+q+oXnrn7WbD5m/A== X-Received: by 2002:ac8:7cb:: with SMTP id m11mr31178900qth.72.1632260415596; Tue, 21 Sep 2021 14:40:15 -0700 (PDT) Received: from [192.168.1.149] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id u11sm202353qke.25.2021.09.21.14.40.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Sep 2021 14:40:15 -0700 (PDT) Message-ID: <20fcad1c-a129-0d8a-d2fb-aac353c3089b@redhat.com> Date: Tue, 21 Sep 2021 17:40:14 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.1 Subject: Re: [PATCH] warn for more impossible null pointer tests [PR102103] To: Martin Sebor , gcc-patches , "Joseph S. Myers" , Jeff Law References: <0858e35e-3271-0dc2-4376-51228645ce79@redhat.com> <40945df3-b63d-87f5-2b9b-e926a24bb8b5@redhat.com> <0f38b998-7894-b8c6-80ff-a822848c9b0b@gmail.com> <8a41e370-7962-7374-f302-8930f8ebeb47@redhat.com> <4ecd02d0-2053-824f-cc42-ced0070f57c9@gmail.com> <037b1948-5467-7333-5a9f-0e7ae75529e9@gmail.com> <57b90a41-a952-80d0-4c3e-a5654415e741@redhat.com> <8526359b-bbd7-3de9-d74f-71005fbefb1d@gmail.com> From: Jason Merrill In-Reply-To: <8526359b-bbd7-3de9-d74f-71005fbefb1d@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP 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, 21 Sep 2021 21:40:21 -0000 On 9/17/21 12:02, Martin Sebor wrote: > On 9/8/21 2:06 PM, Jason Merrill wrote: >> On 9/2/21 7:53 PM, Martin Sebor wrote: >>> @@ -4622,28 +4622,94 @@ warn_for_null_address (location_t location, >>> tree op, tsubst_flags_t complain) >>>     if (!warn_address >>>         || (complain & tf_warning) == 0 >>>         || c_inhibit_evaluation_warnings != 0 >>> -      || warning_suppressed_p (op, OPT_Waddress)) >>> +      || warning_suppressed_p (op, OPT_Waddress) >>> +      || processing_template_decl != 0) >> >> Completely suppressing this warning in templates seems like a >> regression;  I'd think we could recognize many relevant cases before >> instantiation.  You just can't assume that ADDR_EXPR has the default >> meaning if it has unknown type (i.e. because op0 is type-dependent). > > I added the suppression to keep g++.dg/warn/pr101219.C from failing > but in hindsight I should have questioned the reasoning behind > the "no warning emitted here (no instantiation)" comment in the test. > > I agree that it would be helpful to diagnose the type-independent > subset of the problem even in uninstantiated templates.  Current > trunk doesn't (it never has), but with my patch and the suppression > above removed it does.  I've updated the tests to expect it. > > Please see the attached revision. > > Martin > > PS There are still more opportunities to issue -Waddress in templates > that this patch doesn't handle, e.g.,: > >   template bool f (T *p) { return &p == 0; } > > Handling this will take more surgery. > > PPS It seems that most other warnings (and even some errors, like > -Wnarrowing) are suppressed in uninstantiated templates as well, > even for non-dependent expressions.  In the few test cases I looked > at Clang does better.  It sounds like you'd like to see improvements > in this direction not just for -Waddress but in general.  Just for > the avoidance of doubt, can you confirm that for future reference? Yes, in general it's better to diagnose sooner. > + if (TREE_CODE (cop) == NON_LVALUE_EXPR) > + /* Unwrap the expression for C++ 98. */ > + cop = TREE_OPERAND (cop, 0); What does this have to do with C++98? > + if (TREE_CODE (cop) == PTRMEM_CST) > + { > + /* The address of a nonstatic data member is never null. */ > + warning_at (location, OPT_Waddress, > + "the address %qE will never be NULL", Capitalizing NULL when talking about pointers-to-members seems a bit odd, but I guess it's fine. The C++ changes are OK. Jason