From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25248 invoked by alias); 10 May 2012 21:59:28 -0000 Received: (qmail 25235 invoked by uid 22791); 10 May 2012 21:59:26 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 10 May 2012 21:59:10 +0000 From: "DeusExSophismata at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug other/53313] New: Add warning levels Date: Thu, 10 May 2012 22:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: other X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: DeusExSophismata at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-05/txt/msg01149.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 Bug #: 53313 Summary: Add warning levels Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned@gcc.gnu.org ReportedBy: DeusExSophismata@gmail.com The mailing list recently had this thread: http://gcc.gnu.org/ml/gcc/2012-04/msg00087.html A separate, but I think possibly more important issue came up in that thread, starting at this post: http://gcc.gnu.org/ml/gcc/2012-04/msg00395.html Vincent Lefevre mentioned the idea of "warnings levels". So instead of saying gcc -Wall -Wextra you would say gcc -W3 (or something). This is similar to what we do now for optimization levels and debug levels (-gn, -On), but there are a few things that I would like to do differently. First of all, I would have these warnings be entirely meta-warnings. They would only turn on other warning flags. This means that unlike -02, where it turns on some optimizations not enabled by any flag, you could synthesize -W2 by selectively turning on every single warning contained by it. In fact, I believe that all warnings should fall into one of two categories: either they warn for exactly one thing, or they are a collection of warnings. As an example of what I feel should be changed, consider this enhancement request: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651 . -Wextra turns on a few options that are specified by other flags, but it also turns on a few warnings that don't seem to be part of any warning flag. As another example of where this might be helpful, C++ developers have the option Weffc++. It has 7 warnings, some of which appear to be turned on by other warnings (but not all). However, I personally do not use it because one of the 7 warnings it turns on has too many false positives for my code, so I cannot take advantage of the other 6 and still compile with Werror. If Weffc++ were entirely a meta-option, I could turn it on, and then disable that one warning. However, I feel the best solution is the one mentioned in that thread: warning levels. Every warning level would include all of the warnings on the level below. I did a bit of research on the warning levels, and the results of it were posted here: http://stackoverflow.com/questions/5088460/flags-to-enable-thorough-and-verbose-g-warnings/9862800#9862800 This is a rough outline for what I feel the levels should be: -W0: Absolutely no warnings at all. -W1: Warnings that almost never false positive. The discussion on the mailing list seemed to suggest that this would be roughly equivalent to -Wall -Wno-unused -Wno-unitialized. This would likely be the default warning level. -W2: I'm not exactly sure what the guiding principle would be for warnings higher than -W1. My guess would simply be making a judgment call on the ratio of real warnings : false positives, or else entirely based on the number of false positives. For W2 specifically, it would likely be equivalent to -Wall -Wextra. That's a pretty common set of warnings that I see people using, and has a low level of false-positive. I could see a strong argument for making this the default instead of -W1, but either would be a nice improvement. I would probably also add -Winvalid-pch because even though it's unlikely to trigger, if it does, it will generally indicate something is wrong (assuming the user is actually using a pre-compiled header). -W3: A high level of warning. False positives are still tried to avoid, but we could allow style guidelines to be at this level. I suggest something roughly equivalent to: -Wall -Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wformat=2 -Winit-self -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wnoexcept -Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wshadow -Wstrict-null-sentinel -Wstrict-overflow=5 -Wundef -Wuseless-cast -Wzero-as-null-pointer-constant. Some of the warnings in -Weffc++ could be added here if it were split into multiple warnings. This is the set of warnings that I actually recommend for everyone to add in my StackOverflow posting, with a few of the "questionable warnings that are present" removed from the list. -W4: A paranoid level of warning. Likely equivalent to -W3 -Wdisabled-optimization -Wsign-conversion -Wsign-promo -Wstack-protector -Wswitch-default. This is every warning that I recommend turning on in my StackOverflow posting, plus a few that I didn't have just because they are likely to do nothing at all for most users and I didn't want them cluttering the command line even more, but if they are all hiding behind -W4, it won't matter. -W5: I would define this one currently as all the warnings, but it does not necessarily need to always be this. False-positives are not considered for inclusion in this list. It would be (as far as I can tell) -W4 -Wabi -Waggregate-return -Wconversion -Weffc++ -Winline -Wpadded -Wswitch-enum -Wunsafe-loop-optimizations. Ideally, Weffc++ will be split into multiple warnings, some of which are safe to include at a lower level. -Wabi I could see moving down (I had no warnings triggered in my own code when I ran it), but I don't know how important support for multiple-compiler object code is. If we decide it is a bit more important than I rank it, I could see it dropping down to -W4 or -W3. -Wconversion is here because it has so many false-positives. If we get better support for range-propagation in variables to eliminate many of the obviously valid examples, I could see this going up to -W4. -Wunsafe-loop-optimizations is in the same category, it warns about situations that don't even contain user-visible loops currently, but it is useful enough (if the optimization is turned on) for it to merit -W4 if improved. -Winf: Every single warning. This should always be equal to some specified W(number). In this proposal, -Winf and -W5 would be the same thing. However, if we ever decide to expand our warning set, then -Winf would become that new level instead. -Winf has no concerns of maintaining the warning list between releases, it is always defined as every single warning you can possibly turn on, at the max level that the warning supports. I'm not exactly sure where a few warnings should fit in. For instance, -Wpedantic vs. -Wmissing-format-attribute, -Wsuggest-attribute, and some others. My understanding of -Wpedantic is that it will warn if I do use GNU extensions, whereas the others will warn if I don't. Perhaps disable the GNU-extension warnings if -pedantic is explicitly listed (and only enable them at the highest warning level). -Wstrict-aliasing is also a questionable one. It seems that -Wall turns on -Wstrict-aliasing=3, which claims to be the most accurate, but it seems that the loss in accuracy from lower numbers is only an increase in false-positives. If this also means that there is an increase in real-positives (and not just that it takes slightly more analysis time), it may be worth adding -Wstrict-aliasing=1 to higher warning levels. I'm not sure what the internals on this warning are, however. I could also see a case for moving many of the warnings I list at -W3 down to -W2, but my code has been warning free for so long at a level somewhere between -W3 and -W4 (currently I use what I described as -W4 -pedantic -Werror -Wno-unused) that I don't quite know how often those other warnings really trigger.