Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

[Jakub Jelinek <jakub at redhat dot com>]

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.

> > 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.

We also don't warn about division by zero and similar UB after warning
about the obvious cases of those in the FE, such warnings would have
similarly huge false positive rate and again can be handled by
-fsanitize=undefined very well.

	Jakub