[Bug other/53313] New: Add warning levels

["DeusExSophismata at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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.