This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?
- From: Martin Sebor <msebor at gmail dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>, kevin-tucker at cox dot net
- Cc: gcc at gcc dot gnu dot org, dodji at redhat dot com, dmalcolm at redhat dot com
- Date: Mon, 28 Mar 2016 16:32:50 -0600
- Subject: Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?
- Authentication-results: sourceware.org; auth=none
- References: <20160328142309 dot CKMHR dot 556080 dot imail at eastrmwml106> <87r3eul6ki dot fsf at mid dot deneb dot enyo dot de>
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