gcc fails when "-Wall" "-Wno-long-double" parametres used together

[Pasha]

Binary package hint: gcc-4.2

when i'm trying to compile simple C test:
main() {}

with follow flags:
gcc -c -g -Wall -Wno-long-double 1.c

I get follow error:

1.c:1: warning: return type defaults to ‘int’
1.c: In function ‘main’:
1.c:1: warning: control reaches end of non-void function
At top level:
cc1: error: unrecognized command line option "-Wno-long-double"

And it works if I use the flags separately:

$gcc -c -g -Wall 1.c
1.c:1: warning: return type defaults to ‘int’
1.c: In function ‘main’:
1.c:1: warning: control reaches end of non-void function
$ gcc -c -g -Wno-long-double 1.c

System configuration:
Ubuntu 8.04.1
Linux pasha-laptop 2.6.24-21-generic #1 SMP Mon Aug 25 17:32:09 UTC 2008 i686 GNU/Linux

[Debian GCC maintainers (debian-gcc)]

[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'...

[Pinskia (pinskia)]

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.

[7-ian-3 (7-ian-3)]

> 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.

[Manu-gcc (manu-gcc)]

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 <email address hidden>. (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!

[Peter Maydell (pmaydell)]

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.)

[Manu-gcc (manu-gcc)]

(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.

[Peter Maydell (pmaydell)]

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.

[Manu-gcc (manu-gcc)]

(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.

[Manu-gcc (manu-gcc)]

> 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.

[7-ian-3 (7-ian-3)]

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.

[Manu-gcc (manu-gcc)]

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 <email address hidden>

 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

[Manu-gcc (manu-gcc)]

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.

[Manu-gcc (manu-gcc)]

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.

[Peter Maydell (pmaydell)]

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?

[Manu-gcc (manu-gcc)]

(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.

[Manu-gcc (manu-gcc)]

(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).

[Manu-gcc (manu-gcc)]

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).

[Manu-gcc (manu-gcc)]

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 <email address hidden>

 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

[Pinskia (pinskia)]

*** Bug 35961 has been marked as a duplicate of this bug. ***

[Peter Maydell (pmaydell)]

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.)

[Peter Maydell (pmaydell)]

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

[Doko-v (doko-v)]

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 <email address hidden>

        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

[Manu-gcc (manu-gcc)]

Not working on this.

[Ted (tedks)]

I can confirm this bug.

:~$ gcc --version
gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

8.04.1
Linux Stormbringer 2.6.24-21-generic #1 SMP Mon Aug 25 16:57:51 UTC 2008 x86_64 GNU/Linux

[Pasha (pashash)]

Just upgraded gcc to new version and the problem still exists:

gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)

[Jakub-gcc (jakub-gcc)]

*** Bug 39147 has been marked as a duplicate of this bug. ***

[Manu-gcc (manu-gcc)]

Is there anything that remains to be done here?

[Peter Maydell (pmaydell)]

I guess we could use a patch to the docs explaining the new behaviour and the rationale. Code-wise I think we're done.

[Debian GCC maintainers (debian-gcc)]

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
$

[Matthias Klose (doko)]

$ 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
$

[Peter Maydell (pmaydell)]

>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?

[Manu-gcc (manu-gcc)]

Seems to be working according to the original specification (in particular points 1 and 2). The debian bug report is still closed as fixed.

[Debian GCC maintainers (debian-gcc)]

yes, sorry, you are right.

  Matthias

[Manu-gcc (manu-gcc)]

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.

[Matthias Klose (doko)]

works as expected. the warning about the unrecognized command line option is only printed if there are other warnings, otherwise it's ignored. see the upstream report.