From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99300 invoked by alias); 17 Mar 2016 16:45:44 -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 99284 invoked by uid 89); 17 Mar 2016 16:45:44 -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= 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 17 Mar 2016 16:45:43 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id BCD313C23C; Thu, 17 Mar 2016 16:45:41 +0000 (UTC) Received: from [10.3.113.138] (ovpn-113-138.phx2.redhat.com [10.3.113.138]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2HGjevI015014; Thu, 17 Mar 2016 12:45:40 -0400 Subject: Re: C++ PATCH to fix missing warning (PR c++/70194) To: Martin Sebor , Marek Polacek References: <20160315104120.GC10006@redhat.com> <20160315105618.GT3017@tucnak.redhat.com> <20160315120918.GD10006@redhat.com> <56E86580.70800@redhat.com> <20160316144552.GG10006@redhat.com> <56E9FDBB.5070903@gmail.com> Cc: Jakub Jelinek , GCC Patches From: Jason Merrill Message-ID: <56EADF33.7090300@redhat.com> Date: Thu, 17 Mar 2016 16:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E9FDBB.5070903@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg01030.txt.bz2 On 03/16/2016 08:43 PM, Martin Sebor wrote: >> @@ -3974,6 +3974,38 @@ build_vec_cmp (tree_code code, tree type, >> return build3 (VEC_COND_EXPR, type, cmp, minus_one_vec, zero_vec); >> } >> >> +/* Possibly warn about an address never being NULL. */ >> + >> +static void >> +warn_for_null_address (location_t location, tree op, tsubst_flags_t >> complain) >> +{ > ... >> + if (TREE_CODE (cop) == ADDR_EXPR >> + && decl_with_nonnull_addr_p (TREE_OPERAND (cop, 0)) >> + && !TREE_NO_WARNING (cop)) >> + warning_at (location, OPT_Waddress, "the address of %qD will never " >> + "be NULL", TREE_OPERAND (cop, 0)); >> + >> + if (CONVERT_EXPR_P (op) >> + && TREE_CODE (TREE_TYPE (TREE_OPERAND (op, 0))) == REFERENCE_TYPE) >> + { >> + tree inner_op = op; >> + STRIP_NOPS (inner_op); >> + >> + if (DECL_P (inner_op)) >> + warning_at (location, OPT_Waddress, >> + "the compiler can assume that the address of " >> + "%qD will never be NULL", inner_op); > > Since I noted the subtle differences between the phrasing of > the various -Waddress warnings in the bug, I have to ask: what is > the significance of the difference between the two warnings here? The difference is that in the second case, a reference could be bound to a null address, but that has undefined behavior, so the compiler can assume it won't happen. Jason