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