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
