This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 
<https://gcc.gnu.org/ml/gcc/2010-01/msg00063.html>.  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
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]