Am Montag, dem 16.06.2025 um 12:56 -0500 schrieb Segher Boessenkool:
> Hi!
>
> On Sun, Jun 15, 2025 at 04:18:36PM +0200, Martin Uecker wrote:
> > Instead of adding it to -Wextra, here is my attempt to improve this
> > warning as discussed in the PR and make it suitable for -Wall.
> > There were only two tests I had to add -Wno-jump-misses-init.
> >
> > Bootstrapped and regression tested for x86_64.
>
> > c: Revise -Wjump-misses-init to better support idiomatic C code
> > [PR87038]
> >
> > This change revises -Wjump-misses-init to emit a diagnostic only when
> > the
> > variable is read somewhere after the label until the end of the scope,
> > e.g.
> > no warning is emitted anymore in the following example. With this
> > change warning is suitable for -Wall.
> >
> > void f(void)
> > {
> > goto err;
> > int x = 1; // missed initialization
> > f(&x);
> > err:
> > return; // no use of 'x'
> > }
> >
> > This is implemented by deferring all warnings until the end of the
> > scope by
> > recording potential warnings in a data structure, resetting DECL_READ
> > (while recording the current value), and emitting warnings at the end
> > of the scope only for declarations that were read. We still emit
> > diagnostics directly for variably modified types, and for omp
> > allocations,
> > and for all cases with -Wc++-compat.
>
> So, now the warning no longer does what the name says, or what its
> documentation says. Please update the documentation at least!
It still does what the documentation says: It warns for missed initialization,
just not aynmore in some cases where the initialization is irrelevant. I find
the documentation for -Wmaybe-uninitialized more misleading, as it implies
it would detect all cases of possibly uninitialized variables, but it does
not.
But you are right that this change should be added to the documentation.
Thank you for pointing this out.
Martin
>
> The warning was a fine warning before. This change would make a lot of
> sense if it was an error instead, but it isn't. Not even if you use
> -Werror (that flag does not change what is and what isn't a warning or
> an error; it just changes how warnings are handled by the compiler.
> Completly utterly foolish of course, to have compilation ternminated
> abnormally without output whenever the compiler saw something that
> looks suspicious, and as any good heuristic thing it wanted to tell you
> about it, but heh, the user *wanted* pain, that is why he/she used
> -Werror!)
>
> Anyway, please update the documentation for the warning if you change
> what the warning does :-)
>
>
> Segher
