Bug 28322 - GCC new warnings and compatibility
Summary: GCC new warnings and compatibility
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.1.2
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 35961 39147 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-07-08 23:03 UTC by Debian GCC Maintainers
Modified: 2009-12-30 11:19 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-02-27 13:42:28


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Debian GCC Maintainers 2006-07-08 23:03:50 UTC
[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.
Comment 1 Andrew Pinski 2006-07-09 10:41:01 UTC
This is more of a policy issue rather than a bug.

> Occasionally, GCC introduces new warnings.  For example, GCC 4 has
> introduced warnings about discrepancies in signedness of integers
> pointed to by otherwise-compatible pointers.
but it is invalid C (standard C that is) so that case should not be mentioned.


Again this is a policy issue rather than really a bug, I am thinking about closing this as invalid as I thought our policy is clear.
Comment 2 Ian Jackson 2006-10-18 15:11:26 UTC
> Again this is a policy issue rather than really a bug, I am
> thinking about closing this as invalid as I thought our policy is clear.

I'm afraid I don't understand.  What policy are you referring to ?  It seems to me that better treatment of -Wno-this-is-not-a-recognised-warning is a no-brainer.  If my specification is too complicated then simply ignoring unknown -Wno-* options would be a definite improvement.
Comment 3 Manuel López-Ibáñez 2007-01-24 01:15:52 UTC
I agree with most of what you say but, unfortunately, unless someone that can approve a patch for this also agrees, it is pointless even to think about how to implement it. Also, bugzilla is not closely followed by GCC maintainers (except Andrew Pinski, but Andrew is not human, he lives in bugzilla's mind). You may have better luck in gcc@gcc.gnu.org. (if you get ignored, you may need to try a few times, though).

I would recommend to raise one point at a time. For example,

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.

If you get the appropriate maintainer to agree on this point, I volunteer to implement it for GCC 4.3 (subject to my free time, but it will be high in my priority list). You may ever convince the release manager to add it to GCC 4.2 before it is released.

Good luck!
Comment 4 Peter Maydell 2007-02-20 22:23:54 UTC
Manuel: thanks for volunteering to write a patch.

I've just spoken with Joseph Myers (a friend of mine who does gcc development work), and his opinion was that this issue isn't a sufficiently major one for it to be worth trying to make a case on the mailing list beforehand. His recommendation was to submit a patch first. So I think you should feel free to write the patch. (Or I might do it if I find some free time, but that doesn't seem very likely at this point.)
Comment 5 Manuel López-Ibáñez 2007-02-20 22:36:23 UTC
(In reply to comment #4)
> Manuel: thanks for volunteering to write a patch.
> 
> I've just spoken with Joseph Myers (a friend of mine who does gcc development
> work), and his opinion was that this issue isn't a sufficiently major one for
> it to be worth trying to make a case on the mailing list beforehand. His
> recommendation was to submit a patch first. So I think you should feel free to
> write the patch. (Or I might do it if I find some free time, but that doesn't
> seem very likely at this point.)
> 

OK, I will prepare a patch for 1) and 2) when I have some free time. We can deal with 3) later, once the first patch is approved. As far as I know, 4) is the current policy and 5) may not be feasible, since no new features are accepted in old branches.
Comment 6 Peter Maydell 2007-02-20 23:15:40 UTC
I think the point Ian was trying to make with (3) was simply that it doesn't matter whether you choose to implement the reports of unknown -Wno-* (ie (2)) using the existing warning mechanism or by just printing to stderr. So it isn't a separate thing that needs to be done.
Comment 7 Manuel López-Ibáñez 2007-02-20 23:21:59 UTC
(In reply to comment #6)
> I think the point Ian was trying to make with (3) was simply that it doesn't
> matter whether you choose to implement the reports of unknown -Wno-* (ie (2))
> using the existing warning mechanism or by just printing to stderr. So it isn't
> a separate thing that needs to be done.
> 

OK. I misread it, thanks for the clarification. So, nothing to be done for (3) since there is already a mechanism to report unknown options. 
Comment 8 Manuel López-Ibáñez 2007-11-16 20:01:11 UTC
> 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.

Ignoring the -Wno-* seems easy. I am not sure about the proper way to buffer the "unknown option" messages until the end, so we can check whether any warnings (or errors) were produced.

Comment 9 Ian Jackson 2007-11-16 21:18:04 UTC
All that's really needed is to remember all of the unknown -Wno-* options seen.  From the point of view of the core of the option parser, accept them, but just store the string as provided.  When the first warning is printed, print a message about them and clear them out so that the message will not be repeated.

If that's too difficult then it would be better to completely ignore unknown -Wno-* options than to complain about them.
Comment 10 Manuel López-Ibáñez 2008-02-25 23:42:28 UTC
Subject: Bug 28322

Author: manu
Date: Mon Feb 25 23:41:43 2008
New Revision: 132648

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132648
Log:
2008-02-26  Manuel Lopez-Ibanez  <manu@gcc.gnu.org>

	PR 28322
	* toplev.c (toplev_main): If there are warnings or error, print
	errors for ignored options.
	* opts.c (ignored_options): New static variable.
	(postpone_unknown_option_error): New.
	(print_ignored_options): New.
	(handle_option): Postpone errors for unknown -Wno-* options.
	* opts.h (print_ignored_options): Declare.
testsuite/
	* gcc.dg/pr28322.c: New.
	* gcc.dg/pr28322-2.c: New.
	* lib/prune.exp: Ignore "At top level" even if there is no ':'
	preceding it.

Added:
    trunk/gcc/testsuite/gcc.dg/pr28322-2.c
    trunk/gcc/testsuite/gcc.dg/pr28322.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/opts.c
    trunk/gcc/opts.h
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/lib/prune.exp
    trunk/gcc/toplev.c

Comment 11 Manuel López-Ibáñez 2008-02-26 00:59:31 UTC
The main request of this bug (ignore unknown -Wno-* options) has been committed to 4.4. Is there anything else left to do?

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

I am not sure whether this patch would be suitable for backporting. I think we would need a Release Manager to confirm this.
Comment 12 Manuel López-Ibáñez 2008-02-27 12:34:34 UTC
Patches for older branches have been posted here:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01357.html

I hope they are useful and don't break anything ;-)

If there is nothing else to do in this PR, I will close it in a few days.
Comment 13 Peter Maydell 2008-02-27 13:32:52 UTC
Thanks a lot for taking the time to write a patch for this. I do have one question: if I'm reading the patch correctly, this postpones warnings about unrecognised options not just for -Wno-* but also for -fno-* and -mno-*. Was that deliberate?
Comment 14 Manuel López-Ibáñez 2008-02-27 13:42:28 UTC
(In reply to comment #13)
> Thanks a lot for taking the time to write a patch for this. I do have one
> question: if I'm reading the patch correctly, this postpones warnings about
> unrecognised options not just for -Wno-* but also for -fno-* and -mno-*. Was
> that deliberate?

Hum. You are right. I don't think we want to ignore -fno-* and -mno-* options since we don't have a way to detect whether they are unimportant (like we do with -Wno-* options). I'll fix that.
Comment 15 Manuel López-Ibáñez 2008-03-01 16:36:24 UTC
(In reply to comment #13)
> Thanks a lot for taking the time to write a patch for this. I do have one
> question: if I'm reading the patch correctly, this postpones warnings about
> unrecognised options not just for -Wno-* but also for -fno-* and -mno-*. Was
> that deliberate?

Updated patches for older branches have been posted here:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00057.html

They have testcases and have been regression tested. Nonetheless, they won't be reviewed nor applied to GCC branches. (Only the fix for trunk will be reviewed and applied to GCC 4.4).
Comment 16 Manuel López-Ibáñez 2008-03-02 15:19:16 UTC
The patch for gcc 4.3 was a duplicate of the patch for gcc 4.2. The correct patch for gcc 4.3 is here:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00094.html

(thanks to Matthias Klose for noticing this).
Comment 17 Manuel López-Ibáñez 2008-03-04 20:29:37 UTC
Subject: Bug 28322

Author: manu
Date: Tue Mar  4 20:28:52 2008
New Revision: 132870

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132870
Log:
2008-03-04  Manuel Lopez-Ibanez  <manu@gcc.gnu.org>

	PR 28322
	* opts.c (handle_option): Postpone 'unknown option' errors only for
	warning options.
testsuite/
	* gcc.dg/pr28322-3.c: New.

Added:
    trunk/gcc/testsuite/gcc.dg/pr28322-3.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/opts.c
    trunk/gcc/testsuite/ChangeLog

Comment 18 Andrew Pinski 2008-05-05 16:15:33 UTC
*** Bug 35961 has been marked as a duplicate of this bug. ***
Comment 19 Peter Maydell 2008-05-05 17:57:17 UTC
Bug 35961 does suggest that we didn't quite get this patch right, though:
  At top level:
  cc1: error: unrecognized command line option "-Wno-long-double"

The deferred 'unrecognised -Wno*' output should only be a warning, not an error. (In particular, it shouldn't cause compilation to fail if it would otherwise have succeeded, which it looks as if it has done here.)
Comment 20 Peter Maydell 2008-06-05 08:31:28 UTC
I wrote:
>The deferred 'unrecognised -Wno*' output should only be a warning, not an
>error.

I suggested a patch that would correct this:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00139.html
Comment 21 Matthias Klose 2008-07-10 03:51:48 UTC
Subject: Bug 28322

Author: doko
Date: Thu Jul 10 03:51:04 2008
New Revision: 137687

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137687
Log:
2008-07-10  Peter Maydell  <pmaydell@chiark.greenend.org.uk>

        PR other/28322
        * opts.c (print_ignored_options): report postponed diagnostics for
        unknown -Wno-* options as warnings, not errors.
        (postpone_unknown_option_error): renamed to
        postpone_unknown_option_warning.
        * gcc.dg/pr28322-2.c: check that emitted diagnostic for -Wno-foobar
        is a warning and not an error.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/opts.c
    trunk/gcc/testsuite/gcc.dg/pr28322-2.c

Comment 22 Manuel López-Ibáñez 2008-07-22 09:59:25 UTC
Not working on this.
Comment 23 Jakub Jelinek 2009-02-10 18:01:53 UTC
*** Bug 39147 has been marked as a duplicate of this bug. ***
Comment 24 Manuel López-Ibáñez 2009-02-12 00:25:07 UTC
Is there anything that remains to be done here?
Comment 25 Peter Maydell 2009-02-12 08:35:09 UTC
I guess we could use a patch to the docs explaining the new behaviour and the rationale. Code-wise I think we're done.
Comment 26 Debian GCC Maintainers 2009-12-29 15:35:22 UTC
No yet quiet right:

$ cat main.c 
int main() {}
$ gcc -c -g -Wall -Wno-long-double main.c
main.c: In function 'main':
main.c:1:1: warning: control reaches end of non-void function
At top level:
cc1: warning: unrecognized command line option "-Wno-long-double"

only when no other warning is present, the warning about the unrecognized option vanishes:

$ cat main.c 
int main() {return 0;}
$ gcc -c -g -Wall -Wno-long-double main.c
$ 
Comment 27 Peter Maydell 2009-12-29 16:18:31 UTC
>only when no other warning is present, the warning about the unrecognized
>option vanishes:

Um, that is the correct behaviour as described and implemented in this bug, isn't it?


Comment 28 Manuel López-Ibáñez 2009-12-30 01:49:10 UTC
Seems to be working according to the original specification (in particular points 1 and 2). The debian bug report is still closed as fixed.
Comment 29 Debian GCC Maintainers 2009-12-30 11:13:15 UTC
yes, sorry, you are right.

  Matthias
Comment 30 Manuel López-Ibáñez 2009-12-30 11:19:30 UTC
No problem. This was implemented in GCC 4.4 and mentioned in the changes.html page. We haven't received any complaints so far, so closing as FIXED.