PR c/16351 Extend Wnonnull for returns_nonnull

[Jeff Law]

On 07/24/2015 05:15 PM, Trevor Saunders wrote:
>
>>>> 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'm sure I could write one ;-)  And given that a FE based version of this
>>> will only catch explicit NULLs in argument lists, I consider it so weak as
>>> to be virtually useless.
>>
>> Well, it is catching exactly all the cases that you were testing for
>> in your original -Wnull-attribute patch ;-)
>
> maybe, but I'd bet that just means the tests aren't very extensive ;-)
Exactly.  Frankly extending them to cases where they're missed by a 
front-end only solution, but caught after analysis is fairly trivial. 
Pull the constant out into a temporary.  Viola, the front end only 
solution fails miserably.  It's so trivial it didn't seem worth it, but 
with a FE solution in place, it's probably worth it now.


>
>   On the other hand those warnings absolutely require non trivial
>   analysis, so if you can share code between analyzing for warnings and
>   for optimization that seems valuable.  Similarly if you can share the
>   code between languages that seems useful.  Of course that is even more
>   important if you want to catch things that only become visible with
>   inlining.
>
>> For example, Clang is currently able to warn about the following case
>> without any optimization, while GCC cannot at any optimization level:
>
> So at some point we're just talking semantics of words, but I think you
> could make a credible argument that clang doesn't have a true -O0 mode.
> I'm no expert on clang internals, but I think the place they draw a line
> between what is a front end and what is a back is farther back than
> where gcc draws it, but that's basically just a guess.
And that's probably a reasonable way to look at the situation.  We can 
easily put the line at the GENERIC->GIMPLE transition, pay the 
compile-time penalty and generate warnings at that point regardless of 
-O0 or -O2.  We've chosen not to do that so far.  It's a piece of the 
discussion I don't much care about.  If that's the way folks want to go, 
it shouldn't be hard to dust off the work I did a decade or so ago and 
make it work in the current tree.  But I'm not terribly inclined to do 
it myself anymore -- primarily because I weary of arguing one way or the 
other.


Jeff