[forwarded from http://bugs.debian.org/367657]

Summary:

GCC should be more tolerant of
  gcc -Wno-this-is-not-a-recognised-warning
as specified in detail below.


Discussion:

Occasionally, GCC introduces new warnings.  For example, GCC 4 has
introduced warnings about discrepancies in signedness of integers
pointed to by otherwise-compatible pointers.

Furthermore, because GCC has traditionally had such good warnings, and
such good configurability of warnings, and because no-one looks at
warnings that don't cause build failures, many people (myself
included) use -Werror in nearly all of their projects.

However, when new warnings are introduced, there is a problem with the
configurability:  Like any warning, whether or not you want it enabled
depends on your coding style and practices and on other rather
subjective details.  This means that there can be no universally
correct default for a new warning; turning it on by default is
sometimes a reasonable value judgement on the part of the compiler
authors.

When a new warning is introduced and enabled by default, then the
author of a project whose coding style warrants disabling that warning
is faced with a difficult choice:
 * they can set the build system to say -Wno-new-warning (for whatever
   value of `new-warning' is relevant) so that it builds on new
   compilers but so that users of older GCC's need to override the
   build system to remove -Wno-new-warning (which the older GCC
   doesn't understand);
 * they can turn off -Werror, leaving themselves open to the massive
   bugs which are often hidden by warnings which are ignored (perhaps
   bugs which don't show up and aren't warned about on the developer's
   system, because of the various type differences between systems);
 * they can leave things as they are and require users of the new
   compiler to override the build system.
 * they can add complexity to the build system to try to autodetect
   the available compiler options; this usually works but it makes the
   build system more complex - note that in some projects this might
   be the only reason why something like autoconf might be required.
None of these are the right answer.

I would like to propose a straightforward answer which can easily be
implemented in GCC and leaves everything correct.  With this change,
it is much easier to make portable packages which still make good and
strict use of GCC's excellent warnings system.


Specification of the proposed new behaviour:

1. GCC should ignore unknown -Wno-* options if no other warnings are to
   be issued.  This is always correct since the only effect of such an
   option would be to suppress warnings which might otherwise be
   issued.  If no warnings are to be issued at all then treating even
   an unknown suppression as a no-op is clearly correct.

2. If some other warnings are to be issued, then it is necessary to
   report on stderr if any unknown (and therefore unheeded)
   suppressions were in force, in case the user intended for one of
   the relevant suppressions to apply to the warning(s) in question.
   This will alert the user to the lack of support for that
   suppression in this gcc (ie, either to the user's typo or the wrong
   gcc version).  The combination of (1) and (2) will minimise stderr
   noise about unknown suppressions as far as I think is reasonably
   possible.

3. Obviously unknown suppressions ignored according to (1) should not
   count as errors for -Werror.  Whether unknown suppressions reported
   according to (2) should count as as errors for -Werror is not
   important because the actual warning will count as an error for
   -Werror.  So the diagnostic from (2) above can be a real `warning',
   or simply an appropriate message issued to stderr the first time a
   warning is to be issued despite the presence of unknown -Wno-*
   options.

4. Whenever a new GCC warning is introduced, or the scope of an
   existing warning significantly extended, a corresponding -Wno-*
   option should be introduced at the same time.  (AFAIAA current GCC
   development practice seems to abide by this principle.)

5. The changes to implement (1) and (2) should be backported to
   earlier GCCs and earlier Debian branches insofar as practical.