On 2/4/19 11:24 PM, Marc Glisse wrote: > 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). I've had some discussions with Kees and others in this space. The general consensus is that for pure scalars that everyone does a pretty good job at generating good maybe-uninitialized warnings. LLVM and GCC take different approaches, both are valid and both have been useful at giving developers actionable warnings.
However, the general consensus is that for aggregates or anything living in memory is that most compilers aren't doing a particularly good job across the board in this space. Not enough objects are being thoroughly analyzed and those that are analyzed give too many false positives, etc. On the Microsoft side, they've chosen to focus on improving DSE and just initializing everything in memory (presumably flag controlled). It's not clear where LLVM is going to go in this space. ISTM that most of the analysis to do a good job at DSE-ing away the redundant initializer code should play directly into doing a good job at maybe-uninit warnings for objects in memory. However, I don't really have the time to explore here. I would generally support some experimentation in the overall space, that might include allowing for different default settings for uninit warnings of pure scalars vs aggregates/addressables. FWIW, I've been doing Fedora rawhide builds with gcc-9 since early Jan. Not everything builds with -Wall -Werror, but lots of packages do. I've only seen one maybe-uninit warning cause problems -- it was spurious and for a memory object. I didn't dig into it at all. In contrast things like the missing NUL termination warnings, buffer overflow warnings, NULL strings to *printf* warnings, etc all caught numerous (dozens) of real bugs. I mention it because it's one of the ways I know packages are building with -Wall -Werror :-) Jeff
