warning-options.html

gcc手册

evaluation of subexpressions of an expression is not specified.  All
these rules describe only a partial order rather than a total order,
since, for example, if two functions are called within one expression
with no sequence point between them, the order in which the functions
are called is not specified.  However, the standards committee have
ruled that function calls do not overlap.

     <p>It is not specified when between sequence points modifications to the
values of objects take effect.  Programs whose behavior depends on this
have undefined behavior; the C standard specifies that "Between the
previous and next sequence point an object shall have its stored value
modified at most once by the evaluation of an expression.  Furthermore,
the prior value shall be read only to determine the value to be
stored.".  If a program breaks these rules, the results on any
particular implementation are entirely unpredictable.

     <p>Examples of code with undefined behavior are <code>a = a++;</code>, <code>a[n]
= b[n++]</code> and <code>a[i++] = i;</code>.  Some more complicated cases are not
diagnosed by this option, and it may give an occasional false positive
result, but in general it has been found fairly effective at detecting
this sort of problem in programs.

     <p>The present implementation of this option only works for C programs.  A
future implementation may also work for C++ programs.

     <p>The C standard is worded confusingly, therefore there is some debate
over the precise meaning of the sequence point rules in subtle cases. 
Links to discussions of the problem, including proposed formal
definitions, may be found on our readings page, at
<a href="http://gcc.gnu.org/readings.html">http://gcc.gnu.org/readings.html</a>.

     <br><dt><code>-Wreturn-type</code>
     <dd>Warn whenever a function is defined with a return-type that defaults to
<code>int</code>.  Also warn about any <code>return</code> statement with no
return-value in a function whose return-type is not <code>void</code>.

     <p>For C++, a function without return type always produces a diagnostic
message, even when <code>-Wno-return-type</code> is specified.  The only
exceptions are <code>main</code> and functions defined in system headers.

     <br><dt><code>-Wswitch</code>
     <dd>Warn whenever a <code>switch</code> statement has an index of enumeral type
and lacks a <code>case</code> for one or more of the named codes of that
enumeration.  (The presence of a <code>default</code> label prevents this
warning.)  <code>case</code> labels outside the enumeration range also
provoke warnings when this option is used.

     <br><dt><code>-Wswitch-default</code>
     <dd>Warn whenever a <code>switch</code> statement does not have a <code>default</code>
case.

     <br><dt><code>-Wswitch-enum</code>
     <dd>Warn whenever a <code>switch</code> statement has an index of enumeral type
and lacks a <code>case</code> for one or more of the named codes of that
enumeration.  <code>case</code> labels outside the enumeration range also
provoke warnings when this option is used.

     <br><dt><code>-Wtrigraphs</code>
     <dd>Warn if any trigraphs are encountered that might change the meaning of
the program (trigraphs within comments are not warned about).

     <br><dt><code>-Wunused-function</code>
     <dd>Warn whenever a static function is declared but not defined or a
non\-inline static function is unused.

     <br><dt><code>-Wunused-label</code>
     <dd>Warn whenever a label is declared but not used.

     <p>To suppress this warning use the <code>unused</code> attribute
(see <a href="Variable-Attributes.html#Variable%20Attributes">Variable Attributes</a>).

     <br><dt><code>-Wunused-parameter</code>
     <dd>Warn whenever a function parameter is unused aside from its declaration.

     <p>To suppress this warning use the <code>unused</code> attribute
(see <a href="Variable-Attributes.html#Variable%20Attributes">Variable Attributes</a>).

     <br><dt><code>-Wunused-variable</code>
     <dd>Warn whenever a local variable or non-constant static variable is unused
aside from its declaration

     <p>To suppress this warning use the <code>unused</code> attribute
(see <a href="Variable-Attributes.html#Variable%20Attributes">Variable Attributes</a>).

     <br><dt><code>-Wunused-value</code>
     <dd>Warn whenever a statement computes a result that is explicitly not used.

     <p>To suppress this warning cast the expression to <code>void</code>.

     <br><dt><code>-Wunused</code>
     <dd>All the above <code>-Wunused</code> options combined.

     <p>In order to get a warning about an unused function parameter, you must
either specify <code>-W -Wunused</code> or separately specify
<code>-Wunused-parameter</code>.

     <br><dt><code>-Wuninitialized</code>
     <dd>Warn if an automatic variable is used without first being initialized or
if a variable may be clobbered by a <code>setjmp</code> call.

     <p>These warnings are possible only in optimizing compilation,
because they require data flow information that is computed only
when optimizing.  If you don't specify <code>-O</code>, you simply won't
get these warnings.

     <p>These warnings occur only for variables that are candidates for
register allocation.  Therefore, they do not occur for a variable that
is declared <code>volatile</code>, or whose address is taken, or whose size
is other than 1, 2, 4 or 8 bytes.  Also, they do not occur for
structures, unions or arrays, even when they are in registers.

     <p>Note that there may be no warning about a variable that is used only
to compute a value that itself is never used, because such
computations may be deleted by data flow analysis before the warnings
are printed.

     <p>These warnings are made optional because GCC is not smart
enough to see all the reasons why the code might be correct
despite appearing to have an error.  Here is one example of how
this can happen:

     <pre class="smallexample">          {
            int x;
            switch (y)
              {
              case 1: x = 1;
                break;
              case 2: x = 4;
                break;
              case 3: x = 5;
              }
            foo (x);
          }
          </pre>

     <p>If the value of <code>y</code> is always 1, 2 or 3, then <code>x</code> is
always initialized, but GCC doesn't know this.  Here is
another common case:

     <pre class="smallexample">          {
            int save_y;
            if (change_y) save_y = y, y = new_y;
            ...
            if (change_y) y = save_y;
          }
          </pre>

     <p>This has no bug because <code>save_y</code> is used only if it is set.

     <p>This option also warns when a non-volatile automatic variable might be
changed by a call to <code>longjmp</code>.  These warnings as well are possible
only in optimizing compilation.

     <p>The compiler sees only the calls to <code>setjmp</code>.  It cannot know
where <code>longjmp</code> will be called; in fact, a signal handler could
call it at any point in the code.  As a result, you may get a warning
even when there is in fact no problem because <code>longjmp</code> cannot
in fact be called at the place which would cause a problem.

     <p>Some spurious warnings can be avoided if you declare all the functions
you use that never return as <code>noreturn</code>.  See <a href="Function-Attributes.html#Function%20Attributes">Function Attributes</a>.

     <br><dt><code>-Wunknown-pragmas</code>
     <dd>Warn when a #pragma directive is encountered which is not understood by
GCC.  If this command line option is used, warnings will even be issued
for unknown pragmas in system header files.  This is not the case if
the warnings were only enabled by the <code>-Wall</code> command line option.

     <br><dt><code>-Wstrict-aliasing</code>
     <dd>This option is only active when <code>-fstrict-aliasing</code> is active. 
It warns about code which might break the strict aliasing rules that the
compiler is using for optimization. The warning does not catch all
cases, but does attempt to catch the more common pitfalls. It is
included in <code>-Wall</code>.

     <br><dt><code>-Wall</code>
     <dd>All of the above <code>-W</code> options combined.  This enables all the
warnings about constructions that some users consider questionable, and
that are easy to avoid (or modify to prevent the warning), even in
conjunction with macros.  This also enables some language-specific
warnings described in <a href="C---Dialect-Options.html#C++%20Dialect%20Options">C++ Dialect Options</a> and
<a href="Objective-C-Dialect-Options.html#Objective-C%20Dialect%20Options">Objective-C Dialect Options</a>. 
</dl>

   <p>The following <code>-W...</code> options are not implied by <code>-Wall</code>. 
Some of them warn about constructions that users generally do not
consider questionable, but which occasionally you might wish to check
for; others warn about constructions that are necessary or hard to avoid
in some cases, and there is no simple way to modify the code to suppress
the warning.

     <dl>
<dt><code>-W</code>
     <dd>Print extra warning messages for these events:

          <ul>
<li>A function can return either with or without a value.  (Falling
off the end of the function body is considered returning without
a value.)  For example, this function would evoke such a
warning:

          <pre class="smallexample">               foo (a)
               {
                 if (a &gt; 0)
                   return a;
               }
               </pre>

          <li>An expression-statement or the left-hand side of a comma expression
contains no side effects. 
To suppress the warning, cast the unused expression to void. 
For example, an expression such as <code>x[i,j]</code> will cause a warning,
but <code>x[(void)i,j]</code> will not.

          <li>An unsigned value is compared against zero with <code>&lt;</code> or <code>&lt;=</code>.

          <li>A comparison like <code>x&lt;=y&lt;=z</code> appears; this is equivalent to
<code>(x&lt;=y ? 1 : 0) &lt;= z</code>, which is a different interpretation from
that of ordinary mathematical notation.

          <li>Storage-class specifiers like <code>static</code> are not the first things in
a declaration.  According to the C Standard, this usage is obsolescent.

          <li>The return type of a function has a type qualifier such as <code>const</code>. 
Such a type qualifier has no effect, since the value returned by a
function is not an lvalue.  (But don't warn about the GNU extension of
<code>volatile void</code> return types.  That extension will be warned about
if <code>-pedantic</code> is specified.)

          <li>If <code>-Wall</code> or <code>-Wunused</code> is also specified, warn about unused
arguments.

          <li>A comparison between signed and unsigned values could produce an
incorrect result when the signed value is converted to unsigned. 
(But don't warn if <code>-Wno-sign-compare</code> is also specified.)

          <li>An aggregate has a partly bracketed initializer. 
For example, the following code would evoke such a warning,
because braces are missing around the initializer for <code>x.h</code>:

          <pre class="smallexample">               struct s { int f, g; };
               struct t { struct s h; int i; };
               struct t x = { 1, 2, 3 };
               </pre>

          <li>An aggregate has an initializer which does not initialize all members. 
For example, the following code would cause such a warning, because
<code>x.h</code> would be implicitly initialized to zero:

          <pre class="smallexample">               struct s { int f, g, h; };
               struct s x = { 3, 4 };
               </pre>
          </ul>

     <br><dt><code>-Wno-div-by-zero</code>
     <dd>Do not warn about compile-time integer division by zero.  Floating point
division by zero is not warned about, as it can be a legitimate way of
obtaining infinities and NaNs.

     <br><dt><code>-Wsystem-headers</code>
     <dd>Print warning messages for constructs found in system header files. 
Warnings from system headers are normally suppressed, on the assumption
that they usually do not indicate real problems and would only make the
compiler output harder to read.  Using this command line option tells
GCC to emit warnings from system headers as if they occurred in user
code.  However, note that using <code>-Wall</code> in conjunction with this
option will <em>not</em> warn about unknown pragmas in system
headers--for that, <code>-Wunknown-pragmas</code> must also be used.

     <br><dt><code>-Wfloat-equal</code>
     <dd>Warn if floating point values are used in equality comparisons.

     <p>The idea behind this is that sometimes it is convenient (for the
programmer) to consider floating-point values as approximations to