https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92757
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Ricardo Abreu from comment #2)
> Saying "-Wall enables all the warnings that [...]" is inaccurate. Unless you
> consider a very specific interpretation of "enables". Then it is ambiguous,
> because there are other valid (and probably more intuitive) interpretations.
It has an unambiguous meaning:
$ gcc -Q --help=warnings | fgrep maybe-uninit
-Wmaybe-uninitialized [disabled]
$ gcc -Q --help=warnings -Wall | fgrep maybe-uninit
-Wmaybe-uninitialized [enabled]
That's what it means by "enables". Whether a specific diagnostic is emitted for
a specific piece of code is a separate matter (and the whole point of the
-Wmaybe-uninitialied diagnostic is that it's not 100% reliable, that's why it
says "maybe").
> Preventing that ambiguity from arising in the first place would make for
> better documentation. The reader should not have to read on specific
> warnings to find that -Wall, on its own, does not really enable the warnings
> it claims.
I think you've misunderstood what Andrew said. The warning you originally
thought was buggy was:
main.cpp:23:19: error: 'a' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
That tells you which warning has been triggered. If you had read the docs for
-Wmaybe-uninitialized you would see:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized
"These warnings are only possible in optimizing compilation, because
otherwise GCC does not keep track of the state of variables."
The docs for -Wall are not relevant here.
> The interplay of optimization and correctness analysis feels to me too
> general to be left to the documentation of individual warning flags. It is
> something pertaining to a bigger, structural scope.
I've proposed a patch:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00087.html
