On July 23, 2015 7:43:51 PM GMT+02:00, Jeff Law <l...@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 <m...@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 <m...@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 <m...@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 <m...@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 <m...@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..
Thanks,
