[Bug c++/105534] -Wmaybe-uninitialized cases shouldn't suppress -Wuninitialized warnings

["redbeard0531 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105534

--- Comment #3 from Mathias Stearn <redbeard0531 at gmail dot com> ---
One slightly confusing aspect is that the wording of the flag implies that the
variable may or may not be uninitialzied (because in -Wmaybe-uninitialized
maybe binds directly to uninitialized), while phrasing of the warning message
is about the usage being conditional: "may be used uninitialized". And of
course the documentation (at least the man page) uses a different phrasing:

> For an object with automatic or allocated storage duration, if there exists a path from the function entry to a use of the object that is initialized, but there exist some other paths for which the object is not initialized, the compiler emits a warning if it cannot prove the uninitialized paths are not executed at run time.

For both the initial example with count, and your example with count2, I'd say
that the "there exists a path from the function entry to a use of the object
that is initialized" bit is clearly not satisfied, so if we assume the
documentation is correct, then those cases both lack a "maybe" and the
variables are clearly uninitialized.

This would also match my intuition for -Winitialized which is that it
definitively errors if all paths from declaration to any usage result in the
variable being uninitialized.

PS - This test case is a reduced example from an actual bug that luckily was
found by coverity before release: https://jira.mongodb.org/browse/SERVER-66306.
I dug in to make a repro because I was expecting that we would have gotten a
compiler error on that code before it was even committed. I'm also exploring
whether we can stop passing -Wno-maybe-uninitialized, but it looks like we
still get false positives in third-party headers, so it doesn't seem likely.