On July 23, 2015 7:43:51 PM GMT+02:00, Jeff Law <law@redhat.com> wrote:
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 <manu@gcc.gnu.org>
PR c/16351
* doc/invoke.texi (Wnonnull): Document behavior for
returns_nonnull.
gcc/testsuite/ChangeLog:
2015-07-22 Manuel LÃpez-IbÃÃez <manu@gcc.gnu.org>
PR c/16351
* c-c++-common/wnonnull-1.c: New test.
gcc/cp/ChangeLog:
2015-07-22 Manuel LÃpez-IbÃÃez <manu@gcc.gnu.org>
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 <manu@gcc.gnu.org>
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 <manu@gcc.gnu.org>
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.
-W{no-,}{f,m}e IIRC was proposed before. Won't help https://gcc.gnu.org/PR55035 though where struct stores just escape too much -- AFAIU -- but still..