[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.
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.
> 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.
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!
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.)
(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.
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.
(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.
> 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.
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.
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
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.
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.
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?
(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.
(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).
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).
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
*** Bug 35961 has been marked as a duplicate of this bug. ***
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.)
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
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
Not working on this.
*** Bug 39147 has been marked as a duplicate of this bug. ***
Is there anything that remains to be done here?
I guess we could use a patch to the docs explaining the new behaviour and the rationale. Code-wise I think we're done.
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 $
>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?
Seems to be working according to the original specification (in particular points 1 and 2). The debian bug report is still closed as fixed.
yes, sorry, you are right. Matthias
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.