On Tue, 2019-11-26 at 19:33 +0000, Michael Witten wrote: > The problem with false positives is correlated with the degree of > optimization; a lot of people have reported problems at only the > `-Og' optimization level (even when the code in question is > embarrassingly correct). > > Therefore, the general solution is probably that the implem- > entation of `-Wmaybe-uninitialized' be customized for the given > level of optimization. > > However, I get the impression that this is easier said than done. > > From what I've read, `-Wmaybe-uninitialized' is essentially > customized for `-O2', which means that it will work pretty darn > well at that optimization level. So, in the interim, I propose a > simple approximation of the general solution: > > At an optimization level below `-O2' (or other than `-O2'): > > * `-Wmaybe-uninitialized' is moved to `-Wextra'. > > If `-Wall' has been specified, then gcc emits an > informational note stating that `-Wmaybe-uninitialized' (or > any other warning that has similar problems) has been > disabled. > > * Provide a command-line option to disable such a note. > > * The user may always enable `-Wmaybe-uninitialized' either > explicitly or as part of `-Wextra'. > > * If `-Wmaybe-uninitialized' is enabled by the user, then it > implies `-O2' computations. > > That is to say, when the user specifies: > > -Og -Wmaybe-uninitialized > > or: > > -Og -Wextra > > then the user is explicitly telling the compiler to do all > the optimizations of `-O2', but ONLY for the purpose of > implementing `-Wmaybe-uninitialized' (or whichever warning > requires those optimizations to function well); all those > optimizations are to be thrown out after they have been > used to good effect by `-Wmaybe-uninitialized'. The Code > generation, etc., shall be performed at the optimization > level the user specified (namely, `-Og' in this case). > > In other words, save the user from gcc's foibles, but let the > user pay for the extra computation if so desired! > > What do you think? I think this would be a terrible idea. Yes, it's absolutely true that changing options can get you different warning results. Yes it's absolutely true that there are false positives. But, no the warning is not customized to -O2. It's just that O2 enables more optimizations that are particularly good at weeding out false positives.
The whole point behind the uninitialized warning is to capture cases where objects may not be properly initialized. For modern code the simple cases typically "just work". What is by far the most interesting cases are those with complex flow control, often interacting with inline functions, address-of stripping, etc. These are precisely the cases that humans aren't particularly good at catching and having the compiler analyze those paths and issue warnings that humans fix ultimately results in better quality code. Experience has shown that if you put something in -Wall, people will pay attention to it, and that is good for the long term quality of code bases. If the diagnostic is outside of -Wall, it's largely ignored. I think the pain of dealing with the Wuninitialized warts is smaller than the pain of allowing these errors to persist. jeff
