On 02/16/2016 08:36 AM, Richard Biener wrote:
On Tue, 16 Feb 2016, Jakub Jelinek wrote:
Hi!
As has been reported today on gcc@, the new -Wnonnull warning addition
warns even about nonnull parameters that were changed (or could be changed)
in the function. IMHO the nonnull attribute only talks about the value of
the parameter upon entry to the function, if you assign something else
to the argument afterwards and test that for NULL or non-NULL, it is like
any other variable.
But, we don't have the infrastructure to detect this in the FE, so this
patch moves the warning soon after we go into SSA form.
As -Wnonnull is a C/C++/ObjC/ObjC++ only warning, I've added a new
-Wnonnull-compare switch for it too (and enable it for C/C++/ObjC/ObjC++
from -Wall).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Not sure if it matters but wouldn't walking over function parameters
and their default def SSA names immediate uses be cheaper than
matching all conditions? Esp. as nonnull_arg_p walks over all
DECL_ARGUMENTS (up to the searched index) over and over again?
[we should simply set a flag on the PARM_DECL!]
Seems like a waste to burn a flag bit for something like this.
We're already walking all the statements in this code so it's really
just the cost of testing if the existing statement is "interesting" for
this warning. I guess you're suggesting jakub walk the arguments and if
one is a marked as non-null, then walk the immediate uses. Yea, that's
probably faster than doing the test for every statement.
Swapping the nonnull_arg_p and the test for whether or not op1 is 0
would be a slight help as well, particularly if there was machine
generated code with oodles of arguments.
I'm not sure why we're testing OFFSET_TYPE against -1.
warn_uninitialized_vars seems like a poor name if we're warning for
non-null too. So I'd suggest tweaking its name appropriately as well.
Jeff
