On Mon, 4 Feb 2019, Martin Jambor wrote:
Looking for "optional" and "-Wmaybe-uninitialized" shows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78044
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Google also gives
https://www.boost.org/doc/libs/1_69_0/libs/optional/doc/html/boost_optional/tutorial/gotchas/false_positive_with__wmaybe_uninitialized.html
https://sourceware.org/ml/gdb-patches/2017-05/msg00130.html
etc
And that's just for using a type called 'optional' (3 implementations of
it).
from my very quick reading of the first googled testcase, I assume the
instance of the optional class got SRAed and a warning was generated for
what originally was a class member, which indeed is not easy to
initialize on its own in order to avoid the warning.
Hmm, SRA and -Wmaybe-uninitialized, I saw that recently in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66459
Would it perhaps make sense to split the -Wmaybe-uninitialized warning
into two, one for scalars that are scalars in the original code and one
for SRA-created scalars and move only the latter to -Wextra?
If SRA is really the main source of false positives (I don't know about
that), maybe. But I am afraid we will also miss a significant proportion
of the already rare true positives that -Wmaybe-uninitialized currently
finds. I really have no idea if such a split would work great or badly
(sorry, I am not being very useful).
--
Marc Glisse
