On 12/16/2016 10:27 AM, Jakub Jelinek wrote:
On Fri, Dec 16, 2016 at 10:10:00AM -0700, Martin Sebor wrote:
No. The first call to sm_read_sector just doesn't exit. So it is warning
about dead code.
If the code is dead then GCC should eliminate it. With it eliminated
There is (especially with jump threading, but not limited to that, other
optimizations may result in that too), code that even very smart optimizing
compiler isn't able to prove that is dead.
the warning would be gone. The warning isn't smart and it doesn't
try to be. It only works with what GCC gives it. In this case the
dump shows that GCC thinks the code is reachable. If it isn't that
would seem to highlight a missed optimization opportunity, not a need
to make the warning smarter than the optimizer.
No, it highlights that the warning is done in a wrong place where it suffers
from too many false positives.
Asserting a claim without providing any data or evidence doesn't make
it true. We have seen fewer than 10 instances of it in just one out
of four sizable projects. At least three of these instances are
debatable (as evidenced by the ongoing debate). That can hardly be
interpreted as "too many false positives."
But I'm not at all attached to where to implement it and I'm fully
aware that you have a much better idea than me what's the appropriate
place for it. I'll be just as happy if it's done in a pass of its
own just as long as it gives users what they've been asking for.
None look like real bugs to me.
They do to me. There are calls in gengtype.c to a function decorated
with attribute nonnull (lbasename) that pass to it a pointer that's
potentially null. For example below. get_input_file_name returns
Most pointers passed to functions with nonnull attributes are, from the
compiler POV, potentially NULL. Usually the compiler just can't prove it
can't be non-NULL, it is an exception if it can.
If you have a generic function that sometimes can be called with NULL (or
some other "failure" argument) and in that case return NULL, and for valid
arguments it guarantees returning non-NULL (and IMHO the gengtype functions
we talk about fall into that category), then it is not a bug to use this
function and pass the result to functions with nonnull arguments if the
programmer knows it just will not happen. Forcing the programmer to
workaround dubious warnings by throwing in not very portable attributes
everywhere and duplicating functions, so that one copy can be
returns_nonnull and requiring non-NULL argument and another copy allow
NULL argument and allowing NULL returns is just a nightmare we IMHO don't
want to throw at users. If they want to do it, sure, they can, but we
shouldn't force them into that.
I'm not entirely sure I follow your argument here, and not just
because I find your propensity for exaggeration and for pejoratives
distracting. It seems to me that we simply have different views of
what's a true positive and what's not, and what's useful and what's
not. That's likely to be the case for many others and I think it
might help to acknowledge that neither one of us is necessarily
100% right or wrong.
In that spirit let me reiterate that I don't insist on the warning
being implemented in any particular area of the compiler, or even
that it necessarily diagnose any of the cases we've been discussing.
If your implementation diagnoses the common cases exercised by the
tests I wrote I have no objection to it (not that objecting would
do me any good).
Martin
