On Sat, Feb 2, 2019 at 9:20 PM Segher Boessenkool
<seg...@kernel.crashing.org> wrote:
>
> On Fri, Feb 01, 2019 at 12:27:57PM -0700, Jeff Law wrote:
> > On 2/1/19 7:01 AM, Marek Polacek wrote:
> > > On Fri, Feb 01, 2019 at 07:19:25AM -0600, Segher Boessenkool wrote:
> > >> On Fri, Feb 01, 2019 at 12:32:45PM +0100, Marc Glisse wrote:
> > >>> My opinion is that -Wmaybe-uninitialized would serve its purpose better
> > >>> as
> > >>> part of -Wextra.
> > >>
> > >> +1
> > >
> > > +1 from me too.
> > I disagree strongly. If we move it to Wextra it's going to see a lot
> > less usage in real world codebases and potentially lead to the
> > re-introduction of a class of bugs that we've largely helped stomp out.
>
> The usual workaround, especially for programs that build with multiple
> (i.e. older) versions of GCC, is to initialise any such variable (to an
> either or not useful value) early. This doesn't fix the actual problem
> usually (which is that your control flow is too complex).
>
> > It's also the case that maybe uninitialized vs is uninitialized is
> > really just a function of CFG shape. Give me any "maybe uninitialized"
> > case and I can turn it into a "is uninitialized" with simple block
> > duplication of the forms done by jump threading, path isolation,
> > superblock formation, etc.
>
> Are you saying that -Wmaybe-uninitialized should be included in
> -Wuninitialized, since it has no extra false positives? That wasn't true
> at all historically: -Wuninitialized has false positives on paths that
> cannot be executed because of function preconditions, but
> -Wmaybe-uninitialized used to warn for things that can be locally proven to
> never execute, like
> if (a)
> b = 42;
> ...
> if (a)
> f(b);
IMHO the main reason of most false positives is that we rely on SSA
default-defs in PHIs which are spurious when definition and use are
not in domination relation as in
if (p)
a = 1;
if (p)
... = a;
the uninit pass tries to catch those cases but that's obviously hard.
> > >> Yes, using -Werror is usually a terrible idea.
> > Generally agreed in released versions of any code. -Werror *may* be
> > appropriate in development versions depending on the project's policies,
> > procedures and quality of codebase.
>
> IMO it is more useful it is much more useful if you make your build system
> less noisy so that problems are more obvious, instead of breaking the build
> for no reason all the time (see PR89162, etc. etc.)
>
>
> Segher
