On 2/4/19 3:52 PM, Martin Jambor wrote: > Hi, > > On Mon, Feb 04 2019, Marc Glisse wrote: >> On Mon, 4 Feb 2019, Martin Sebor wrote: >>> > > ... > >>> You're right that this is hard to imagine without first hand experience >>> with the problem. If this is a common pattern with the warning in C++ >>> class templates in general, a representative test case would help get >>> a better appreciation of the problem and might also give us an idea >>> of a better solution. (If there is one in Bugzilla please point me >>> at it.) >> >> 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. > > 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? I could support that. It fits in with the general sense that we're not handling aggregates and addressables as well as we could.
JEff
