[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 Richard Biener changed: What|Removed |Added CC||vincent-gcc at vinc17 dot net --- Comment #15 from Richard Biener --- *** Bug 99014 has been marked as a duplicate of this bug. ***
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||10.0 Resolution|--- |FIXED --- Comment #14 from Richard Biener --- Fixed for GCC 10.
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 --- Comment #13 from CVS Commits --- The master branch has been updated by Richard Guenther : https://gcc.gnu.org/g:abe13e1847fb91d43f02b5579c4230214d4369f4 commit r10-6668-gabe13e1847fb91d43f02b5579c4230214d4369f4 Author: Richard Biener Date: Mon Feb 17 09:32:44 2020 +0100 c/86134 avoid errors for unrecognized -Wno- options This makes sure to not promote diagnostics about unrecognized -Wno- options to errors and make the intent of the diagnostic clearer. 2020-02-17 Richard Biener PR c/86134 * opts-global.c (print_ignored_options): Use inform and amend message. * gcc.dg/pr86134.c: New testcase. * gcc.dg/pr28322-2.c: Adjust.
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-14 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #12 from Richard Biener --- I have a patch.
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
--- Comment #11 from Pádraig Brady ---
I agree that -Wno-... should never be promoted to an error as we see with:
$ echo 'int maint(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall -Werror
-Wextra -Wno-error=return-type -
: In function ‘maint’:
:1:1: warning: control reaches end of non-void function [-Wreturn-type]
: At top level:
cc1: error: unrecognized command line option ‘-Wno-unknown-warning-option’
[-Werror]
cc1: all warnings being treated as errors
However it's worth noting that one can suppress the other warnings entirely
that trigger the promotion. This may be ok as a workaround for some:
$ echo 'int maint(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall -Werror
-Wextra -Wno-return-type -
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
--- Comment #10 from joseph at codesourcery dot com ---
On Fri, 15 Jun 2018, rguenth at gcc dot gnu.org wrote:
> Joseph, do you agree that the following shouldn't fail the compilation?
>
> > echo 'int main(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall -Werror
> > -Wno-error=return-type -
> : In function ‘main’:
> :1:1: warning: control reaches end of non-void function [-Wreturn-type]
> : At top level:
> cc1: error: unrecognized command line option "-Wno-unknown-warning-option"
> [-Werror]
> cc1: all warnings being treated as errors
Yes.
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 --- Comment #9 from Manuel López-Ibáñez --- That makes sense as well. Adding further logic to silence the warning or to make the warning not become an error is what I think is a bad idea. I like also your more explicit wording.
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
--- Comment #8 from rguenther at suse dot de ---
On Fri, 15 Jun 2018, lopezibanez at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
>
> --- Comment #7 from Manuel López-Ibáñez ---
> What I'm suggesting is to add an option to control this warning, which is
> currently enabled by default. Then you can use -Wno-error or even -Wno- to
> make it always a warning or completely disable it. This what clang does.
That sounds reasonable but then don't you have a chicken-and-egg
issue because you'd need to say
-Wno-unknown-warning-option
which when not known in old compilers will cause the very same issue
with -Werror ...
What's bad about changing the diagnostic to be emitted as a note
after the very first warning that is emitted? So
> echo 'int main(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall
-Werror -Wno-error=return-type -
: In function ‘main’:
:1:1: warning: control reaches end of non-void function
[-Wreturn-type]
: note: unrecognized command line option "-Wno-unknown-warning-option"
may have silenced this or further diagnostics
...
? Which also makes the intent of the warning more explicit.
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 --- Comment #7 from Manuel López-Ibáñez --- What I'm suggesting is to add an option to control this warning, which is currently enabled by default. Then you can use -Wno-error or even -Wno- to make it always a warning or completely disable it. This what clang does.
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #6 from Richard Biener ---
(In reply to Manuel López-Ibáñez from comment #5)
> (In reply to rguent...@suse.de from comment #4)
> > fails the compile but with the warning not emitted the error isn't
> > emitted. Also we do know the warning is guarded by -Wreturn-type
> > so I see no point in warning that it wasn't silenced by
> > -Wno-unknown-warning-option?
>
> I see what you mean: The warning that could have been silenced did not
> prevent compilation but the warning about the unknown option did. However,
>
> 1) Given -Wno-foo, there is no way to know if you actually meant -Wno-f
> or, -Wfoo is an alias for -Wreturn-type in some other version of GCC. Maybe
> you really meant to write -Wno-return-type but you mistyped it as -Wno-foo.
> The current behavior means "There is at least one diagnostic that could
> have been silenced by -Wno-foo, but this GCC does not recognize -Wfoo, maybe
> you gave the wrong option?"
>
> 2) The warning behaves like any other warning: It gets converted to an error
> with -Werror. Imagine an example where GCC gives both a warning [-Wfooo] and
> a warning converted to an error [-Werror=f], what should we report for
> -Wno-fo ?
>
> We can alleviate (2) by giving it a name (clang uses
> -Wunknown-warning-option) so that you can do:
>
> gcc -S -x c -Wall -Werror -Wno-error=return-type
> -Wno-error=unknown-warning-option -Wno-foo
There is no way to specify that the diagnostic about the unknown
-Wno-unknown-warning-option should not be promoted to an error.
-Wno-error=unknown-warning-option and variants do not work because
the option isn't known. The diagnostic lists [-Werror] so the only
option is to disable -Werror.
In general I question that we raise a diagnostic at all here but
I can live with that. But this diagnostic about unknown options
should never be promoted to errors from warnings IMHO.
> Another example:
>
> gcc -S -x c -Wall -Werror -Wno-misleading-identation -Wno-future
>
> If there is no warning emitted, there is no harm in the above -Wno- options.
>
> If there is a warning emitted, it will get converted to an error, and GCC
> does not know if you actually meant -Wno-misleading-indentation. And maybe
> you really want to use -Wno-future for a future -Wfuture enabled by -Wall,
> and you don't care but you want the same command-line to work on previous
> GCC versions so giving an extra warning (or error) or may be you really
> meant the warning used to be called -Wmisleading-identation, but it got
> renamed.
Sure. But if you come back to my case where I had -Werror and specifically
disabled promoting a specific warning to an error then I got what I wanted
and there's no point in erroring for the unknown warning option.
I guess a solution would be to not emit a warning about the unknown option
but a note (using inform).
Joseph, do you agree that the following shouldn't fail the compilation?
> echo 'int main(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall -Werror
> -Wno-error=return-type -
: In function ‘main’:
:1:1: warning: control reaches end of non-void function [-Wreturn-type]
: At top level:
cc1: error: unrecognized command line option "-Wno-unknown-warning-option"
[-Werror]
cc1: all warnings being treated as errors
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez --- (In reply to rguent...@suse.de from comment #4) > fails the compile but with the warning not emitted the error isn't > emitted. Also we do know the warning is guarded by -Wreturn-type > so I see no point in warning that it wasn't silenced by > -Wno-unknown-warning-option? I see what you mean: The warning that could have been silenced did not prevent compilation but the warning about the unknown option did. However, 1) Given -Wno-foo, there is no way to know if you actually meant -Wno-f or, -Wfoo is an alias for -Wreturn-type in some other version of GCC. Maybe you really meant to write -Wno-return-type but you mistyped it as -Wno-foo. The current behavior means "There is at least one diagnostic that could have been silenced by -Wno-foo, but this GCC does not recognize -Wfoo, maybe you gave the wrong option?" 2) The warning behaves like any other warning: It gets converted to an error with -Werror. Imagine an example where GCC gives both a warning [-Wfooo] and a warning converted to an error [-Werror=f], what should we report for -Wno-fo ? We can alleviate (2) by giving it a name (clang uses -Wunknown-warning-option) so that you can do: gcc -S -x c -Wall -Werror -Wno-error=return-type -Wno-error=unknown-warning-option -Wno-foo Another example: gcc -S -x c -Wall -Werror -Wno-misleading-identation -Wno-future If there is no warning emitted, there is no harm in the above -Wno- options. If there is a warning emitted, it will get converted to an error, and GCC does not know if you actually meant -Wno-misleading-indentation. And maybe you really want to use -Wno-future for a future -Wfuture enabled by -Wall, and you don't care but you want the same command-line to work on previous GCC versions so giving an extra warning (or error) or may be you really meant the warning used to be called -Wmisleading-identation, but it got renamed. The long history can be found here: https://gcc.gnu.org/wiki/FAQ#wnowarning
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
--- Comment #4 from rguenther at suse dot de ---
On Wed, 13 Jun 2018, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
>
> --- Comment #3 from Martin Sebor ---
> As per the recent discussion:
> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00422.html
But the warning should never be elided to an error with -Werror.
> echo 'int main(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall
-Werror -Wno-error=return-type -
: In function ‘main’:
:1:1: warning: control reaches end of non-void function
[-Wreturn-type]
: At top level:
cc1: error: unrecognized command line option "-Wno-unknown-warning-option"
[-Werror]
cc1: all warnings being treated as errors
fails the compile but with the warning not emitted the error isn't
emitted. Also we do know the warning is guarded by -Wreturn-type
so I see no point in warning that it wasn't silenced by
-Wno-unknown-warning-option?
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 --- Comment #3 from Martin Sebor --- As per the recent discussion: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00422.html
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- I thought this was by design? I.e., that warnings about unknown -Wno- options were suppressed unless/until a different kind of a warning is emitted.
[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
Richard Biener changed:
What|Removed |Added
Summary|earlier error causes|earlier diagnostic causes
|followup diagnostic about |followup diagnostic about
|unknown -Wno-* options |unknown -Wno-* options
Known to fail||4.8.5, 8.1.0
--- Comment #1 from Richard Biener ---
Also
> echo 'int main(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall -Werror
> -Wno-error=return-type -
: In function ‘main’:
:1:1: warning: control reaches end of non-void function [-Wreturn-type]
: At top level:
cc1: error: unrecognized command line option "-Wno-unknown-warning-option"
[-Werror]
cc1: all warnings being treated as errors
> echo $?
1
> echo 'int main(){}' | gcc -S -x c -Wno-unknown-warning-option -Wreturn-type -
: In function ‘main’:
:1:1: warning: control reaches end of non-void function [-Wreturn-type]
: At top level:
cc1: warning: unrecognized command line option "-Wno-unknown-warning-option"
[enabled by default]
