Bug 31573 - -Wall-all to enable all warnings
Summary: -Wall-all to enable all warnings
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.0.1
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 47824 53313 66293 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-04-14 14:44 UTC by John Love-Jensen
Modified: 2017-04-24 16:19 UTC (History)
10 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Love-Jensen 2007-04-14 14:44:29 UTC
The ability to enable absolutely all warnings (-Wall -Wextra -Wyada-yada-yada), and then selectively disable the one's that are not desired.  Rather than the opposite.

Example:
g++ -c -Wall-all -Wno-unreachable-code -Wno-long-long -Wno-four-char-constants test.cpp -o test.o
Comment 1 David Fang 2007-04-14 20:27:55 UTC
That begs the question: what's *not* covered by -W -Wall -Wextra [-ansi -pedantic-errors -Werror]?

There are also some warning flags that are parameterized (-Wstrict-aliasing=#, -Wformat=#), should those be maxed out as well?

Maybe we could call it -WALL?  :)
Comment 2 Andrew Pinski 2007-04-14 21:18:43 UTC
Actually more than that, there are new warnings options each release so really if we have this we will get complaints about warnings options get added. so I am going to close this as won't fix.
Comment 3 David Fang 2007-04-14 22:24:21 UTC
Subject: Re:  -Wall-all to enable all warnings

> ------- Comment #2 from pinskia at gcc dot gnu dot org  2007-04-14 21:18 -------
> Actually more than that, there are new warnings options each release so really
> if we have this we will get complaints about warnings options get added. so I
> am going to close this as won't fix.

I also don't really see this ever happening because the libstdc++ headers
aren't clean w.r.t. -Weffc++ (if you propose to turn those on too).  Even
the man page warns about it.  (Vast majority seem to be "non-virtual
destructor in base class" nonsense from my previous attempts.)  Even if
fine-grain, source-annotated warning suppressions (__attribute__, etc.)
kick in, *some* of the extra warnings would be a nuisance to work-around,
and extra work for library maintainers.  FWIW, -W -Wall has served me
quite well.  (-W is -Wextra since 3.4)


Comment 4 Andrew Pinski 2011-02-20 20:42:02 UTC
*** Bug 47824 has been marked as a duplicate of this bug. ***
Comment 5 Jakub Jelinek 2011-02-21 12:55:51 UTC
*** Bug 47824 has been marked as a duplicate of this bug. ***
Comment 6 Jonathan Wakely 2015-05-26 19:38:09 UTC
*** Bug 66293 has been marked as a duplicate of this bug. ***
Comment 7 Manuel López-Ibáñez 2016-02-15 22:51:59 UTC
*** Bug 53313 has been marked as a duplicate of this bug. ***
Comment 8 Manuel López-Ibáñez 2016-02-15 23:16:24 UTC
Marc, in reply to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313#c10

I see there may be value in a -Weverything flag for debugging (and to check if something already warns for a specific testcase). I believe it will be useless for users, but, hey, I'm happy if the description warns users profusely about it, so we don't get a tsunami of reports complaining that "it warns too much".

Your proposed patch (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313#c5) is probably a good start. It probably doesn't maximize warnings that take several levels (like Wstrict-overflow=) or warnings that internally have several levels (like Wmain).

You should only need to convince Joseph or Dodji.