Feature request: -Wno-unknown-warnings to silently ignore unknown warning control flags.

[Andrew Pinski]

)4.On Thu, Oct 12, 2017 at 1:46 AM, Oren Ben-Kiki <gcc-oren@ben-kiki.org> wrote:
> Motivation/Use case:
>
> * Since gcc/g++ intentionally does not have `-Weverything`, there is a
> number of explicit `-W...` flags one might wish to specify explicitly. Fair
> enough.
>
> * Additional `-W...` flags are introduced in new gcc/g++ versions, which
> check for new potential code smells, possibly related to later language
> standards. That's great (thanks!).
>
> * Not all platforms run the latest gcc/g++ compiler version. So build tools
> need to deal with a range of versions.
>
> Taking these three points together, we have a problem. The build tool
> wishes to specify `-Wshiny-new-warning` but may only do so if the gcc/g++
> compiler version is above some version X.
>
> This is difficult for several reasons:
>
> * The documentation does not clearly specify the 1st compiler version that
> supports each error/warning command line flag. One has to manually
> backtrack through the release notes for all the compiler versions.
>
> In fact the documentation also doesn't make it easy to see which flags are
> covered by other flags - one has to read through the documentation, one
> flag at a time, and extract the information from the English text. Some
> form of a more structured table would have been awesome: 1st compiler
> version supporting the flag, the list of other flags such as `-Wall` that
> imply the flag, maybe a list of related flags such as `-f...`. But that
> aside...
>
> * Even if we know which compiler version to check for, this quickly becomes
> a PITA to maintain in the build tool, given the large number of compiler
> versions in use in the wild. Having many versions means the compiler has
> been actively progressing at a fast rate, which is great! But it makes it
> nasty to deal with providing the correct warning flags for the correct
> compiler version.
>
> This is (mostly) solved with the new proposed flag: the build tool would
> simply list all the desired warning flags, which would be silently ignored
> by older compiler versions.
>
> Typos are a potential issue. One would have to run a "recent" version
> without the `-Wno-unknown-warnings` to catch such typos; that would be
> rare, and is simple enough to do (and automate in the build tool if
> desired).
>
> Another obvious issue is that the new `-Wno-unknown-warnings` flag would
> only be available starting in a future compiler version. So build tools
> would have to deal with the problem for a long time before the flag would
> provide its full benefits. Barring having a working time machine ;-)
>
> However, it is much simpler for a build tool to do a single test of whether
> or not the compiler version supports the proposed new flag, than to deal
> with the full problem of multiple versions. If the new flag is not
> supported, the build tool could fall back to using a conservative set of
> warning flags.
>
> Also, as time goes by, older compiler versions would eventually be phased
> out, so even this test would be (eventually) removed. Sure, it would take a
> decade or more, but: as the saying goes, "The best time to plant a tree is
> 20 years ago; the second best time is today".

-Wno-unkown-warning has already been handled silently since 4.6.0
(which was released March 25, 2011):
https://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Warning-Options.html

When an unrecognized warning option is requested (e.g.,
-Wunknown-warning), GCC emits a diagnostic stating that the option is
not recognized. However, if the -Wno- form is used, the behavior is
slightly different: no diagnostic is produced for -Wno-unknown-warning
unless other diagnostics are being produced. This allows the use of
new -Wno- options with old compilers, but if something goes wrong, the
compiler warns that an unrecognized option is present.


Thanks,
Andrew Pinski


>
> Thanks,
>
> Oren Ben-Kiki