From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126845 invoked by alias); 17 Mar 2016 16:49:05 -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 126506 invoked by uid 89); 17 Mar 2016 16:49:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy= X-HELO: mail-oi0-f65.google.com Received: from mail-oi0-f65.google.com (HELO mail-oi0-f65.google.com) (209.85.218.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 17 Mar 2016 16:48:53 +0000 Received: by mail-oi0-f65.google.com with SMTP id c129so4928651oif.3 for ; Thu, 17 Mar 2016 09:48:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=O9P7NF+a3XcFD6TwSMSnfcqJEK+f5fojjQJC4XvnRNY=; b=lVJsabUS51mvvw6cZMrOgpI4JnIZXana2I86KHEsqTKzPv0SnsZxazpBxUu8+wSLMR gT4gWgImDBkTQznPJsHCio+SC8fxgCIWilcx5Dox2T+YZ3wGMoCKHF/oALPblQ4zt7MY ZG6fKcnzWrDenMYQSQwx78KqKnY5S0Lw9GE43q6zFda+haULs0DeyhPgyt/7LCWUu2Ji eb7ySQuCxe4/FRMdoy+ithHe/DrQ/ZIbtdahUIkXvpyD1/A4ZPkMZH6cUM/hugnDT4jK p6TKuxv4vXh6nWNInaZ2eE1VbhKCMYbuuJwnGvCpJFXFfJAy54/An5mp3w8O4z3qIYbc DAAg== X-Gm-Message-State: AD7BkJI2bhfq2QAPhT2He+TQerQCKFzVZGqpQHPXKE447Dxh06MuKR0c1Ej0pcALbbABlCvSrCst0sgc1RQh0A== X-Received: by 10.202.98.133 with SMTP id w127mr5933803oib.136.1458233330605; Thu, 17 Mar 2016 09:48:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.29.226 with HTTP; Thu, 17 Mar 2016 09:48:30 -0700 (PDT) In-Reply-To: <56EADB0E.3010304@redhat.com> 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> <56EADB0E.3010304@redhat.com> From: Patrick Palka Date: Thu, 17 Mar 2016 16:49:00 -0000 Message-ID: Subject: Re: C++ PATCH to fix missing warning (PR c++/70194) To: Jeff Law Cc: Martin Sebor , Marek Polacek , Jason Merrill , Jakub Jelinek , GCC Patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-03/txt/msg01032.txt.bz2 On Thu, Mar 17, 2016 at 12:27 PM, Jeff Law wrote: > On 03/16/2016 06: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) =3D=3D 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))) =3D=3D REFERENCE= _TYPE) >>> + { >>> + tree inner_op =3D 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? >> >> Would it not be appropriate to issue the first warning in the latter >> case? Or perhaps even use the same text as is already used elsewhere: >> "the address of %qD will always evaluate as =E2=80=98true=E2=80=99" (sin= ce it may not >> be the macro NULL that's mentioned in the expression). > > They were added at different times AFAICT. The former is fairly old > (Douglas Gregor, 2008) at this point. The latter was added by Patrick Pa= lka > for 65168 about a year ago. > > You could directly ask Patrick about motivations for a different message. There is no plausible way for the address of a non-reference variable to be NULL even in code with UB (aside from __attribute__ ((weak)) in which case the warning is suppressed). But the address of a reference can easily seem to be NULL if one performs UB and assigns to it *(int *)NULL or something like that. I think that was my motivation, anyway :)