From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43462 invoked by alias); 23 Jul 2015 17:43:55 -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 43436 invoked by uid 89); 23 Jul 2015 17:43:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 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, 23 Jul 2015 17:43:53 +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 4A936AC84F; Thu, 23 Jul 2015 17:43:52 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-54.phx2.redhat.com [10.3.113.54]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6NHhpw1025265; Thu, 23 Jul 2015 13:43:51 -0400 Subject: Re: PR c/16351 Extend Wnonnull for returns_nonnull To: =?UTF-8?B?TWFudWVsIEzDs3Blei1JYsOhw7Fleg==?= , Gcc Patch List , Jason Merrill , "Joseph S. Myers" References: From: Jeff Law Message-ID: <55B127D7.3020202@redhat.com> Date: Thu, 23 Jul 2015 17:52:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg01961.txt.bz2 On 07/22/2015 09:29 AM, Manuel López-Ibáñez wrote: > While looking at PR c/16351, I noticed that all tests proposed for > -Wnull-attribute > (https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01715.html) could be > warned from the FEs by simply extending the existing Wnonnull. > > Bootstrapped and regression tested on x86_64-linux-gnu. > > OK? > > > gcc/ChangeLog: > > 2015-07-22 Manuel López-Ibáñez > > PR c/16351 > * doc/invoke.texi (Wnonnull): Document behavior for > returns_nonnull. > > gcc/testsuite/ChangeLog: > > 2015-07-22 Manuel López-Ibáñez > > PR c/16351 > * c-c++-common/wnonnull-1.c: New test. > > gcc/cp/ChangeLog: > > 2015-07-22 Manuel López-Ibáñez > > PR c/16351 > * typeck.c (check_return_expr): Call maybe_warn_returns_nonnull. > > > gcc/c-family/ChangeLog: > > 2015-07-22 Manuel López-Ibáñez > > PR c/16351 > * c-common.c (maybe_warn_returns_nonnull): New. > * c-common.h (maybe_warn_returns_nonnull): Declare. > > gcc/c/ChangeLog: > > 2015-07-22 Manuel López-Ibáñez > > PR c/16351 > * c-typeck.c (c_finish_return): Call maybe_warn_returns_nonnull. FWIW, we have the usual tension here between warning in the front-end vs warning after optimization and exploiting dataflow analysis. Warning in the front-ends like this can generate false positives (such as a NULL return in an unreachable path and miss cases where the NULL has to be propagated into the return by later optimizations. However warning in the front-ends will tend to have more stable diagnostics from release to release. Warning after optimization/analysis will tend to generate fewer false positives and can pick up cases where the didn't explicitly appear in the return statement, but had to be propagated in by the optimizers. Of course, these warnings are less stable release-to-release and require the optimizers/analysis phases to be run. I've always preferred exploiting optimization and analysis to both reduce false positives and expose the non-trivial which show up via optimizations. But I also understand that's simply my preference and that others have a different preference. I'll tentatively approve for the trunk, but I think we still want warnings after optimization/analysis. Which will likely lead to a scheme like I proposed many years for uninitialized variables where we have multiple modes. One warns in the front-end like your implemention does, the other defers the warning until after analysis & optimization. So please keep 16351 open after committing. Jeff