[Bug other/28322] New: GCC new warnings and compatibility
debian-gcc at lists dot debian dot org
gcc-bugzilla@gcc.gnu.org
Sat Jul 8 23:04:00 GMT 2006
[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.
--
Summary: GCC new warnings and compatibility
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28322
More information about the Gcc-bugs
mailing list