Re: PR c/16351 Extend Wnonnull for returns_nonnull

[Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>]

On 23 July 2015 at 19:43, Jeff Law <law@redhat.com> wrote:
> 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.

False positives (for the warning as proposed right now) would be
strange, since it would mean that a returns_nonnull function returns
an explicit NULL in some code-path that is not meant to be executed.
That sounds like a bug waiting to happen.

Moreover, this warning works in exactly the same cases as
__attribute__((nonnull)) does for function arguments, and so far those
haven't been a source of false positives.

> 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'm very much in favour of this, but only for things that cannot
reliably be warned from the FE. Clang has shown that it is possible to
improve much more the accuracy of warnings in the FE and still compile
faster than GCC by performing some kind of fast CCP (and VRP?) in the
FE  (or make the CCP and VRP passes occur earlier and even without
optimization):

https://gcc.gnu.org/PR38470 is just one example that would be very
much improved by some trivial VRP.

> 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.

Isn't this what we already have with -Wuninitialized and -Wmaybe-uninitialized?

It would be OK to get warnings for returning NULL implicitly (either
by propagation, inlining, VRP). I plan to leave 16351 open for that
(or open a new PR). However, in this case, I also think it makes sense
to follow what -Wnonnull already does and always warn for any explicit
"return NULL", even if the code as currently written is never
executed. The two things are not incompatible.

> So please keep 16351 open after committing.

Of course, there is also
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01860.html pending
review.

Cheers,

Manuel.