Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[Jeff Law]

On 03/31/2016 09:39 PM, Martin Sebor wrote:

On 03/31/2016 10:30 AM, Segher Boessenkool wrote:

On Mon, Mar 28, 2016 at 04:32:50PM -0600, Martin Sebor wrote:

On 03/28/2016 01:56 PM, Florian Weimer wrote:

In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though
he provides the "-Werror=return-type" option, the compiler doesn't
flag the warning/error about a control reaching the end of a non-void
function, due to the presence of the "-w" option.  He points out that
clang++ wtill flags the promoted warning even though warnings are
inhibited.


I think -w is ordered with respect to the other warning obtions, and
-w inhibits previously requested warnings, and future -W flags may
enable other warnings.  With this in mind, I agree that the current
GCC behavior is consistent and probably not a bug.


The general rule of thumb documented in the manual is that more
specific options take precedence over more general ones, regardless
of where they appear on the command line:


Currently, -w is a nice easy quick way of shutting up all warnings
whenever they are getting in the way.  Let's keep it that way.


I agree that having a knob to suppress all warnings can be useful.

At the same time, having the ability to do what PR 70275 asks for
(i.e., suppress only warnings that have not be been explicitly
enabled or elevated to errors) can be handy as well.  If it's
preferable to keep -w unchanged, providing a new option to do it
might be worth considering.

Given the long standing behavior of -w, I think it should remain unchanged.

jeff

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[Manuel López-Ibáñez]

On 01/04/16 04:39, Martin Sebor wrote:

At the same time, having the ability to do what PR 70275 asks for
(i.e., suppress only warnings that have not be been explicitly
enabled or elevated to errors) can be handy as well.  If it's
preferable to keep -w unchanged, providing a new option to do it
might be worth considering.


Some users have asked for -Weverything in the past (to turn on all possible 
warnings unless a more specific -Wno- option is provided). Perhaps 
-Wno-everything should do the opposite: turn off all warnings unless a more 
specific -Wfoo option is provided. I'm still not sure what would be the 
expected behavior in the presence of #pragmas.


Nonetheless, one still would need to fix the bug I mentioned in my previous 
email so that -Werror=foo is the same as -Wfoo -Werror=foo.


As Joseph mentioned, somebody has to come up with a set of consistent rules and 
then see how much of the rules GCC satisfies and whether it is worth it to 
break backwards compatibility or to modify the rules. One would need to inspect 
the code, since some options are set outside the code generated by the .awk 
scripts, and thus not follow the same rules (or extend the awk scripts to 
support those options).


Cheers,

Manuel.

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[Martin Sebor]

On 03/31/2016 10:30 AM, Segher Boessenkool wrote:

On Mon, Mar 28, 2016 at 04:32:50PM -0600, Martin Sebor wrote:

On 03/28/2016 01:56 PM, Florian Weimer wrote:

In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though
he provides the "-Werror=return-type" option, the compiler doesn't
flag the warning/error about a control reaching the end of a non-void
function, due to the presence of the "-w" option.  He points out that
clang++ wtill flags the promoted warning even though warnings are
inhibited.


I think -w is ordered with respect to the other warning obtions, and
-w inhibits previously requested warnings, and future -W flags may
enable other warnings.  With this in mind, I agree that the current
GCC behavior is consistent and probably not a bug.


The general rule of thumb documented in the manual is that more
specific options take precedence over more general ones, regardless
of where they appear on the command line:


Currently, -w is a nice easy quick way of shutting up all warnings
whenever they are getting in the way.  Let's keep it that way.


I agree that having a knob to suppress all warnings can be useful.

At the same time, having the ability to do what PR 70275 asks for
(i.e., suppress only warnings that have not be been explicitly
enabled or elevated to errors) can be handy as well.  If it's
preferable to keep -w unchanged, providing a new option to do it
might be worth considering.

Martin

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[Segher Boessenkool]

On Thu, Mar 31, 2016 at 06:34:12PM +0200, Florian Weimer wrote:
> * Segher Boessenkool:
> 
> > On Mon, Mar 28, 2016 at 04:32:50PM -0600, Martin Sebor wrote:
> >> On 03/28/2016 01:56 PM, Florian Weimer wrote:
> >> >>In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though
> >> >>he provides the "-Werror=return-type" option, the compiler doesn't
> >> >>flag the warning/error about a control reaching the end of a non-void
> >> >>function, due to the presence of the "-w" option.  He points out that
> >> >>clang++ wtill flags the promoted warning even though warnings are
> >> >>inhibited.
> >> >
> >> >I think -w is ordered with respect to the other warning obtions, and
> >> >-w inhibits previously requested warnings, and future -W flags may
> >> >enable other warnings.  With this in mind, I agree that the current
> >> >GCC behavior is consistent and probably not a bug.
> >> 
> >> The general rule of thumb documented in the manual is that more
> >> specific options take precedence over more general ones, regardless
> >> of where they appear on the command line:
> >
> > Currently, -w is a nice easy quick way of shutting up all warnings
> > whenever they are getting in the way.  Let's keep it that way.
> 
> You mean, by putting -w towards the end of the command line?

Either that or how it is now (always turn off everything, wherever -w is
on the command line); but certainly not "more specific overrides less
specific".  -w turns off all warnings, it's a very useful feature.


Segher

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[Florian Weimer]

* Segher Boessenkool:

> On Mon, Mar 28, 2016 at 04:32:50PM -0600, Martin Sebor wrote:
>> On 03/28/2016 01:56 PM, Florian Weimer wrote:
>> >>In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though
>> >>he provides the "-Werror=return-type" option, the compiler doesn't
>> >>flag the warning/error about a control reaching the end of a non-void
>> >>function, due to the presence of the "-w" option.  He points out that
>> >>clang++ wtill flags the promoted warning even though warnings are
>> >>inhibited.
>> >
>> >I think -w is ordered with respect to the other warning obtions, and
>> >-w inhibits previously requested warnings, and future -W flags may
>> >enable other warnings.  With this in mind, I agree that the current
>> >GCC behavior is consistent and probably not a bug.
>> 
>> The general rule of thumb documented in the manual is that more
>> specific options take precedence over more general ones, regardless
>> of where they appear on the command line:
>
> Currently, -w is a nice easy quick way of shutting up all warnings
> whenever they are getting in the way.  Let's keep it that way.

You mean, by putting -w towards the end of the command line?

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[Segher Boessenkool]

On Mon, Mar 28, 2016 at 04:32:50PM -0600, Martin Sebor wrote:
> On 03/28/2016 01:56 PM, Florian Weimer wrote:
> >>In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though
> >>he provides the "-Werror=return-type" option, the compiler doesn't
> >>flag the warning/error about a control reaching the end of a non-void
> >>function, due to the presence of the "-w" option.  He points out that
> >>clang++ wtill flags the promoted warning even though warnings are
> >>inhibited.
> >
> >I think -w is ordered with respect to the other warning obtions, and
> >-w inhibits previously requested warnings, and future -W flags may
> >enable other warnings.  With this in mind, I agree that the current
> >GCC behavior is consistent and probably not a bug.
> 
> The general rule of thumb documented in the manual is that more
> specific options take precedence over more general ones, regardless
> of where they appear on the command line:

Currently, -w is a nice easy quick way of shutting up all warnings
whenever they are getting in the way.  Let's keep it that way.

[ Most warnings are heuristic, so they misfire sometimes. ]


Segher

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[Manuel López-Ibáñez]

On 30/03/16 00:01, Joseph Myers wrote:

If we consider that -Wno-general implies -Wno-specific and
-Werror=specific implies -Wspecific,@equal levels of indirection, then
the order of the options on the command line is what determines whether
-Wspecific is enabled (as an error).  If however we consider -Wspecific to
be a tristate (disabled, warning, error), then -Werror=specific is a
direct setting of the tristate while -Wno-general is only indirect, so
-Werror=specific takes precedence whatever the command-line order.


Internally, they are tri-state but -Werror= does not seem to update opts_set, 
which is what is tested by the options machinery for options that imply other 
options. That is,


 -Werror=return-type -Wreturn-type  -Wno-all

is different from

 -Werror=return-type -Wno-all

This seems a bug to me in how -Werror= works.

Cheers,

Manuel.

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[Joseph Myers]

On Mon, 28 Mar 2016, Martin Sebor wrote:

> The general rule of thumb documented in the manual is that more
> specific options take precedence over more general ones, regardless
> of where they appear on the command line:
> 
>   The combined effect of positive and negative forms [of warning
>   options] is that more specific options have priority over less
>   specific ones, independently of their position in the command-
>   line.

As a matter of compatibility, I think it's best to keep existing semantics 
for -w, and document them more precisely, rather than change -w to act 
like a less-specific option "for each warning, disable that warning's 
option implicitly".

Note that there is another ambiguity in the general rule about more 
specific options overriding less specific options when it relates to 
-Werror= / -Wno-error= options.  An idealized form of that rule (not 
actually implemented) is described in appendix 1 in 
.  Now consider 
-Wgeneral implying -Wspecific, and look at the interaction between 
-Wno-general and -Werror=specific.

If we consider that -Wno-general implies -Wno-specific and 
-Werror=specific implies -Wspecific, at equal levels of indirection, then 
the order of the options on the command line is what determines whether 
-Wspecific is enabled (as an error).  If however we consider -Wspecific to 
be a tristate (disabled, warning, error), then -Werror=specific is a 
direct setting of the tristate while -Wno-general is only indirect, so 
-Werror=specific takes precedence whatever the command-line order.

I make no assertion here regarding what the semantics are currently (not 
necessarily consistent), or should ideally be, for this case.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[kevin-tucker]

I apologize for stating that you had reported the issue.  I copy/pasted from 
your comment rather than the original report.
The issue was reported by Teodor Petrov 

Kevin

 "Manuel López-Ibáñez"  wrote: 
> > On 03/28/2016 01:56 PM, Florian Weimer wrote:
> >>> In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though
> >>> he provides the "-Werror=return-type" option, the compiler doesn't
> >>> flag the warning/error about a control reaching the end of a non-void
> >>> function, due to the presence of the "-w" option.  He points out that
> >>> clang++ wtill flags the promoted warning even though warnings are
> >>> inhibited.
> 
> I did not report the bug and did not mention anything of the above. I only 
> commented on why GCC works like it works and how one can change the behaviour 
> if so desired. I don't care one way or the other and I can see benefits for 
> either behaviour.
> 
> >> I think -w is ordered with respect to the other warning obtions, and
> >> -w inhibits previously requested warnings, and future -W flags may
> >> enable other warnings.  With this in mind, I agree that the current
> >> GCC behavior is consistent and probably not a bug.
> 
> The command-line order does not affect '-w' and there is no way to undo '-w'. 
> It is a global boolean switch independent of anything else (including 
> pragmas) 
> that disables warnings just before they are re-classified (by pragmas or 
> -Werror=) into something else. This means that if -Wfoobar is given in the 
> command-line (or enabled by a pragma) and it requires an expensive analysis, 
> this analysis is done even in the presence of -w, only the warning message is 
> not emitted.
> 
> One question to answer if the behaviour does change is what would be the 
> effect 
> of using '-w' on warning options enabled by #pragmas. Some people may still 
> want a switch that simply disables all warnings no matter how they are 
> enabled.
> 
> Cheers,
> 
>   Manuel.

Re: Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[Manuel López-Ibáñez]

On 03/28/2016 01:56 PM, Florian Weimer wrote:

In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though
he provides the "-Werror=return-type" option, the compiler doesn't
flag the warning/error about a control reaching the end of a non-void
function, due to the presence of the "-w" option.  He points out that
clang++ wtill flags the promoted warning even though warnings are
inhibited.


I did not report the bug and did not mention anything of the above. I only 
commented on why GCC works like it works and how one can change the behaviour 
if so desired. I don't care one way or the other and I can see benefits for 
either behaviour.



I think -w is ordered with respect to the other warning obtions, and
-w inhibits previously requested warnings, and future -W flags may
enable other warnings.  With this in mind, I agree that the current
GCC behavior is consistent and probably not a bug.


The command-line order does not affect '-w' and there is no way to undo '-w'. 
It is a global boolean switch independent of anything else (including pragmas) 
that disables warnings just before they are re-classified (by pragmas or 
-Werror=) into something else. This means that if -Wfoobar is given in the 
command-line (or enabled by a pragma) and it requires an expensive analysis, 
this analysis is done even in the presence of -w, only the warning message is 
not emitted.


One question to answer if the behaviour does change is what would be the effect 
of using '-w' on warning options enabled by #pragmas. Some people may still 
want a switch that simply disables all warnings no matter how they are enabled.


Cheers,

Manuel.

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[Martin Sebor]

On 03/28/2016 01:56 PM, Florian Weimer wrote:

In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though
he provides the "-Werror=return-type" option, the compiler doesn't
flag the warning/error about a control reaching the end of a non-void
function, due to the presence of the "-w" option.  He points out that
clang++ wtill flags the promoted warning even though warnings are
inhibited.


I think -w is ordered with respect to the other warning obtions, and
-w inhibits previously requested warnings, and future -W flags may
enable other warnings.  With this in mind, I agree that the current
GCC behavior is consistent and probably not a bug.


The general rule of thumb documented in the manual is that more
specific options take precedence over more general ones, regardless
of where they appear on the command line:

  The combined effect of positive and negative forms [of warning
  options] is that more specific options have priority over less
  specific ones, independently of their position in the command-
  line.

The manual doesn't give an exhaustive list of the more general
options but it mentions -Wall and -Wextra as examples.  I would
tend to view -w as another such example and, like the reporter,
expect "-Werror=return-type -w" to disable all warnings but treat
-Wreturn-type as an error.

Martin

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[Florian Weimer]

> In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though
> he provides the "-Werror=return-type" option, the compiler doesn't
> flag the warning/error about a control reaching the end of a non-void
> function, due to the presence of the "-w" option.  He points out that
> clang++ wtill flags the promoted warning even though warnings are
> inhibited.

I think -w is ordered with respect to the other warning obtions, and
-w inhibits previously requested warnings, and future -W flags may
enable other warnings.  With this in mind, I agree that the current
GCC behavior is consistent and probably not a bug.