компилятор C и C ++ проекта GNU (GNU project C and C++ compiler)
Параметры подробно (Options detail)
Request or Suppress Warnings - 1
Warnings are diagnostic messages that report constructions that
are not inherently erroneous but that are risky or suggest there
may have been an error.
The following language-independent options do not enable specific
warnings but control the kinds of diagnostics produced by GCC.
-fsyntax-only
Check the code for syntax errors, but don't do anything
beyond that.
-fmax-errors=n
Limits the maximum number of error messages to n, at which
point GCC bails out rather than attempting to continue
processing the source code. If n is 0 (the default), there
is no limit on the number of error messages produced. If
-Wfatal-errors is also specified, then -Wfatal-errors takes
precedence over this option.
-w Inhibit all warning messages.
-Werror
Make all warnings into errors.
-Werror=
Make the specified warning into an error. The specifier for
a warning is appended; for example -Werror=switch turns the
warnings controlled by -Wswitch into errors. This switch
takes a negative form, to be used to negate -Werror for
specific warnings; for example -Wno-error=switch makes
-Wswitch warnings not be errors, even when -Werror is in
effect.
The warning message for each controllable warning includes
the option that controls the warning. That option can then
be used with -Werror= and -Wno-error= as described above.
(Printing of the option in the warning message can be
disabled using the -fno-diagnostics-show-option flag.)
Note that specifying -Werror=foo automatically implies -Wfoo.
However, -Wno-error=foo does not imply anything.
-Wfatal-errors
This option causes the compiler to abort compilation on the
first error occurred rather than trying to keep going and
printing further error messages.
You can request many specific warnings with options beginning
with -W, for example -Wimplicit to request warnings on implicit
declarations. Each of these specific warning options also has a
negative form beginning -Wno- to turn off warnings; for example,
-Wno-implicit. This manual lists only one of the two forms,
whichever is not the default. For further language-specific
options also refer to C++ Dialect Options and Objective-C and
Objective-C++ Dialect Options.
Some options, such as -Wall and -Wextra, turn on other options,
such as -Wunused, which may turn on further options, such as
-Wunused-value. The combined effect of positive and negative
forms is that more specific options have priority over less
specific ones, independently of their position in the command-
line. For options of the same specificity, the last one takes
effect. Options enabled or disabled via pragmas take effect as if
they appeared at the end of the command-line.
When an unrecognized warning option is requested (e.g.,
-Wunknown-warning), GCC emits a diagnostic stating that the
option is not recognized. However, if the -Wno- form is used,
the behavior is slightly different: no diagnostic is produced for
-Wno-unknown-warning unless other diagnostics are being produced.
This allows the use of new -Wno- options with old compilers, but
if something goes wrong, the compiler warns that an unrecognized
option is present.
The effectiveness of some warnings depends on optimizations also
being enabled. For example -Wsuggest-final-types is more
effective with link-time optimization and -Wmaybe-uninitialized
will not warn at all unless optimization is enabled.
-Wpedantic
-pedantic
Issue all the warnings demanded by strict ISO C and ISO C++;
reject all programs that use forbidden extensions, and some
other programs that do not follow ISO C and ISO C++. For ISO
C, follows the version of the ISO C standard specified by any
-std option used.
Valid ISO C and ISO C++ programs should compile properly with
or without this option (though a rare few require -ansi or a
-std option specifying the required version of ISO C).
However, without this option, certain GNU extensions and
traditional C and C++ features are supported as well. With
this option, they are rejected.
-Wpedantic does not cause warning messages for use of the
alternate keywords whose names begin and end with __.
Pedantic warnings are also disabled in the expression that
follows "__extension__". However, only system header files
should use these escape routes; application programs should
avoid them.
Some users try to use -Wpedantic to check programs for strict
ISO C conformance. They soon find that it does not do quite
what they want: it finds some non-ISO practices, but not
all---only those for which ISO C requires a diagnostic, and
some others for which diagnostics have been added.
A feature to report any failure to conform to ISO C might be
useful in some instances, but would require considerable
additional work and would be quite different from -Wpedantic.
We don't have plans to support such a feature in the near
future.
Where the standard specified with -std represents a GNU
extended dialect of C, such as gnu90 or gnu99, there is a
corresponding base standard, the version of ISO C on which
the GNU extended dialect is based. Warnings from -Wpedantic
are given where they are required by the base standard. (It
does not make sense for such warnings to be given only for
features not in the specified GNU C dialect, since by
definition the GNU dialects of C include all features the
compiler supports with the given option, and there would be
nothing to warn about.)
-pedantic-errors
Give an error whenever the base standard (see -Wpedantic)
requires a diagnostic, in some cases where there is undefined
behavior at compile-time and in some other cases that do not
prevent compilation of programs that are valid according to
the standard. This is not equivalent to -Werror=pedantic,
since there are errors enabled by this option and not enabled
by the latter and vice versa.
-Wall
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 C++ Dialect Options and Objective-C and
Objective-C++ Dialect Options.
-Wall turns on the following warning flags:
-Waddress -Warray-bounds=1 (only with -O2) -Wbool-compare
-Wbool-operation -Wc++11-compat -Wc++14-compat -Wcatch-value
(C++ and Objective-C++ only) -Wchar-subscripts -Wcomment
-Wduplicate-decl-specifier (C and Objective-C only)
-Wenum-compare (in C/ObjC; this is on by default in C++)
-Wformat -Wint-in-bool-context -Wimplicit (C and Objective-C
only) -Wimplicit-int (C and Objective-C only)
-Wimplicit-function-declaration (C and Objective-C only)
-Winit-self (only for C++) -Wlogical-not-parentheses -Wmain
(only for C/ObjC and unless -ffreestanding)
-Wmaybe-uninitialized -Wmemset-elt-size
-Wmemset-transposed-args -Wmisleading-indentation (only for
C/C++) -Wmissing-attributes -Wmissing-braces (only for
C/ObjC) -Wmultistatement-macros -Wnarrowing (only for C++)
-Wnonnull -Wnonnull-compare -Wopenmp-simd -Wparentheses
-Wpessimizing-move (only for C++) -Wpointer-sign -Wreorder
-Wrestrict -Wreturn-type -Wsequence-point -Wsign-compare
(only in C++) -Wsizeof-pointer-div -Wsizeof-pointer-memaccess
-Wstrict-aliasing -Wstrict-overflow=1 -Wswitch
-Wtautological-compare -Wtrigraphs -Wuninitialized
-Wunknown-pragmas -Wunused-function -Wunused-label
-Wunused-value -Wunused-variable -Wvolatile-register-var
Note that some warning flags are not implied by -Wall. 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. Some
of them are enabled by -Wextra but many of them must be
enabled individually.
-Wextra
This enables some extra warning flags that are not enabled by
-Wall. (This option used to be called -W. The older name is
still supported, but the newer name is more descriptive.)
-Wclobbered -Wcast-function-type -Wdeprecated-copy (C++ only)
-Wempty-body -Wignored-qualifiers -Wimplicit-fallthrough=3
-Wmissing-field-initializers -Wmissing-parameter-type (C
only) -Wold-style-declaration (C only) -Woverride-init
-Wsign-compare (C only) -Wredundant-move (only for C++)
-Wtype-limits -Wuninitialized -Wshift-negative-value (in
C++03 and in C99 and newer) -Wunused-parameter (only with
-Wunused or -Wall) -Wunused-but-set-parameter (only with
-Wunused or -Wall)
The option -Wextra also prints warning messages for the
following cases:
* A pointer is compared against integer zero with "<",
"<=", ">", or ">=".
* (C++ only) An enumerator and a non-enumerator both appear
in a conditional expression.
* (C++ only) Ambiguous virtual bases.
* (C++ only) Subscripting an array that has been declared
"register".
* (C++ only) Taking the address of a variable that has been
declared "register".
* (C++ only) A base class is not initialized in the copy
constructor of a derived class.
-Wchar-subscripts
Warn if an array subscript has type "char". This is a common
cause of error, as programmers often forget that this type is
signed on some machines. This warning is enabled by -Wall.
-Wno-coverage-mismatch
Warn if feedback profiles do not match when using the
-fprofile-use option. If a source file is changed between
compiling with -fprofile-generate and with -fprofile-use, the
files with the profile feedback can fail to match the source
file and GCC cannot use the profile feedback information. By
default, this warning is enabled and is treated as an error.
-Wno-coverage-mismatch can be used to disable the warning or
-Wno-error=coverage-mismatch can be used to disable the
error. Disabling the error for this warning can result in
poorly optimized code and is useful only in the case of very
minor changes such as bug fixes to an existing code-base.
Completely disabling the warning is not recommended.
-Wno-cpp
(C, Objective-C, C++, Objective-C++ and Fortran only)
Suppress warning messages emitted by "#warning" directives.
-Wdouble-promotion (C, C++, Objective-C and Objective-C++ only)
Give a warning when a value of type "float" is implicitly
promoted to "double". CPUs with a 32-bit "single-precision"
floating-point unit implement "float" in hardware, but
emulate "double" in software. On such a machine, doing
computations using "double" values is much more expensive
because of the overhead required for software emulation.
It is easy to accidentally do computations with "double"
because floating-point literals are implicitly of type
"double". For example, in:
float area(float radius)
{
return 3.14159 * radius * radius;
}
the compiler performs the entire computation with "double"
because the floating-point literal is a "double".
-Wduplicate-decl-specifier (C and Objective-C only)
Warn if a declaration has duplicate "const", "volatile",
"restrict" or "_Atomic" specifier. This warning is enabled
by -Wall.
-Wformat
-Wformat=n
Check calls to "printf" and "scanf", etc., to make sure that
the arguments supplied have types appropriate to the format
string specified, and that the conversions specified in the
format string make sense. This includes standard functions,
and others specified by format attributes, in the "printf",
"scanf", "strftime" and "strfmon" (an X/Open extension, not
in the C standard) families (or other target-specific
families). Which functions are checked without format
attributes having been specified depends on the standard
version selected, and such checks of functions without the
attribute specified are disabled by -ffreestanding or
-fno-builtin.
The formats are checked against the format features supported
by GNU libc version 2.2. These include all ISO C90 and C99
features, as well as features from the Single Unix
Specification and some BSD and GNU extensions. Other library
implementations may not support all these features; GCC does
not support warning about features that go beyond a
particular library's limitations. However, if -Wpedantic is
used with -Wformat, warnings are given about format features
not in the selected standard version (but not for "strfmon"
formats, since those are not in any version of the C
standard).
-Wformat=1
-Wformat
Option -Wformat is equivalent to -Wformat=1, and
-Wno-format is equivalent to -Wformat=0. Since -Wformat
also checks for null format arguments for several
functions, -Wformat also implies -Wnonnull. Some aspects
of this level of format checking can be disabled by the
options: -Wno-format-contains-nul,
-Wno-format-extra-args, and -Wno-format-zero-length.
-Wformat is enabled by -Wall.
-Wno-format-contains-nul
If -Wformat is specified, do not warn about format
strings that contain NUL bytes.
-Wno-format-extra-args
If -Wformat is specified, do not warn about excess
arguments to a "printf" or "scanf" format function. The
C standard specifies that such arguments are ignored.
Where the unused arguments lie between used arguments
that are specified with $ operand number specifications,
normally warnings are still given, since the
implementation could not know what type to pass to
"va_arg" to skip the unused arguments. However, in the
case of "scanf" formats, this option suppresses the
warning if the unused arguments are all pointers, since
the Single Unix Specification says that such unused
arguments are allowed.
-Wformat-overflow
-Wformat-overflow=level
Warn about calls to formatted input/output functions such
as "sprintf" and "vsprintf" that might overflow the
destination buffer. When the exact number of bytes
written by a format directive cannot be determined at
compile-time it is estimated based on heuristics that
depend on the level argument and on optimization. While
enabling optimization will in most cases improve the
accuracy of the warning, it may also result in false
positives.
-Wformat-overflow
-Wformat-overflow=1
Level 1 of -Wformat-overflow enabled by -Wformat
employs a conservative approach that warns only about
calls that most likely overflow the buffer. At this
level, numeric arguments to format directives with
unknown values are assumed to have the value of one,
and strings of unknown length to be empty. Numeric
arguments that are known to be bounded to a subrange
of their type, or string arguments whose output is
bounded either by their directive's precision or by a
finite set of string literals, are assumed to take on
the value within the range that results in the most
bytes on output. For example, the call to "sprintf"
below is diagnosed because even with both a and b
equal to zero, the terminating NUL character ('\0')
appended by the function to the destination buffer
will be written past its end. Increasing the size of
the buffer by a single byte is sufficient to avoid
the warning, though it may not be sufficient to avoid
the overflow.
void f (int a, int b)
{
char buf [13];
sprintf (buf, "a = %i, b = %i\n", a, b);
}
-Wformat-overflow=2
Level 2 warns also about calls that might overflow
the destination buffer given an argument of
sufficient length or magnitude. At level 2, unknown
numeric arguments are assumed to have the minimum
representable value for signed types with a precision
greater than 1, and the maximum representable value
otherwise. Unknown string arguments whose length
cannot be assumed to be bounded either by the
directive's precision, or by a finite set of string
literals they may evaluate to, or the character array
they may point to, are assumed to be 1 character
long.
At level 2, the call in the example above is again
diagnosed, but this time because with a equal to a
32-bit "INT_MIN" the first %i directive will write
some of its digits beyond the end of the destination
buffer. To make the call safe regardless of the
values of the two variables, the size of the
destination buffer must be increased to at least 34
bytes. GCC includes the minimum size of the buffer
in an informational note following the warning.
An alternative to increasing the size of the
destination buffer is to constrain the range of
formatted values. The maximum length of string
arguments can be bounded by specifying the precision
in the format directive. When numeric arguments of
format directives can be assumed to be bounded by
less than the precision of their type, choosing an
appropriate length modifier to the format specifier
will reduce the required buffer size. For example,
if a and b in the example above can be assumed to be
within the precision of the "short int" type then
using either the %hi format directive or casting the
argument to "short" reduces the maximum required size
of the buffer to 24 bytes.
void f (int a, int b)
{
char buf [23];
sprintf (buf, "a = %hi, b = %i\n", a, (short)b);
}
-Wno-format-zero-length
If -Wformat is specified, do not warn about zero-length
formats. The C standard specifies that zero-length
formats are allowed.
-Wformat=2
Enable -Wformat plus additional format checks. Currently
equivalent to -Wformat -Wformat-nonliteral
-Wformat-security -Wformat-y2k.
-Wformat-nonliteral
If -Wformat is specified, also warn if the format string
is not a string literal and so cannot be checked, unless
the format function takes its format arguments as a
"va_list".
-Wformat-security
If -Wformat is specified, also warn about uses of format
functions that represent possible security problems. At
present, this warns about calls to "printf" and "scanf"
functions where the format string is not a string literal
and there are no format arguments, as in "printf (foo);".
This may be a security hole if the format string came
from untrusted input and contains %n. (This is currently
a subset of what -Wformat-nonliteral warns about, but in
future warnings may be added to -Wformat-security that
are not included in -Wformat-nonliteral.)
-Wformat-signedness
If -Wformat is specified, also warn if the format string
requires an unsigned argument and the argument is signed
and vice versa.
-Wformat-truncation
-Wformat-truncation=level
Warn about calls to formatted input/output functions such
as "snprintf" and "vsnprintf" that might result in output
truncation. When the exact number of bytes written by a
format directive cannot be determined at compile-time it
is estimated based on heuristics that depend on the level
argument and on optimization. While enabling
optimization will in most cases improve the accuracy of
the warning, it may also result in false positives.
Except as noted otherwise, the option uses the same logic
-Wformat-overflow.
-Wformat-truncation
-Wformat-truncation=1
Level 1 of -Wformat-truncation enabled by -Wformat
employs a conservative approach that warns only about
calls to bounded functions whose return value is
unused and that will most likely result in output
truncation.
-Wformat-truncation=2
Level 2 warns also about calls to bounded functions
whose return value is used and that might result in
truncation given an argument of sufficient length or
magnitude.
-Wformat-y2k
If -Wformat is specified, also warn about "strftime"
formats that may yield only a two-digit year.
-Wnonnull
Warn about passing a null pointer for arguments marked as
requiring a non-null value by the "nonnull" function
attribute.
-Wnonnull is included in -Wall and -Wformat. It can be
disabled with the -Wno-nonnull option.
-Wnonnull-compare
Warn when comparing an argument marked with the "nonnull"
function attribute against null inside the function.
-Wnonnull-compare is included in -Wall. It can be disabled
with the -Wno-nonnull-compare option.
-Wnull-dereference
Warn if the compiler detects paths that trigger erroneous or
undefined behavior due to dereferencing a null pointer. This
option is only active when -fdelete-null-pointer-checks is
active, which is enabled by optimizations in most targets.
The precision of the warnings depends on the optimization
options used.
-Winit-self (C, C++, Objective-C and Objective-C++ only)
Warn about uninitialized variables that are initialized with
themselves. Note this option can only be used with the
-Wuninitialized option.
For example, GCC warns about "i" being uninitialized in the
following snippet only when -Winit-self has been specified:
int f()
{
int i = i;
return i;
}
This warning is enabled by -Wall in C++.
-Wimplicit-int (C and Objective-C only)
Warn when a declaration does not specify a type. This
warning is enabled by -Wall.
-Wimplicit-function-declaration (C and Objective-C only)
Give a warning whenever a function is used before being
declared. In C99 mode (-std=c99 or -std=gnu99), this warning
is enabled by default and it is made into an error by
-pedantic-errors. This warning is also enabled by -Wall.
-Wimplicit (C and Objective-C only)
Same as -Wimplicit-int and -Wimplicit-function-declaration.
This warning is enabled by -Wall.
-Wimplicit-fallthrough
-Wimplicit-fallthrough is the same as
-Wimplicit-fallthrough=3 and -Wno-implicit-fallthrough is the
same as -Wimplicit-fallthrough=0.
-Wimplicit-fallthrough=n
Warn when a switch case falls through. For example:
switch (cond)
{
case 1:
a = 1;
break;
case 2:
a = 2;
case 3:
a = 3;
break;
}
This warning does not warn when the last statement of a case
cannot fall through, e.g. when there is a return statement or
a call to function declared with the noreturn attribute.
-Wimplicit-fallthrough= also takes into account control flow
statements, such as ifs, and only warns when appropriate.
E.g.
switch (cond)
{
case 1:
if (i > 3) {
bar (5);
break;
} else if (i < 1) {
bar (0);
} else
return;
default:
...
}
Since there are occasions where a switch case fall through is
desirable, GCC provides an attribute, "__attribute__
((fallthrough))", that is to be used along with a null
statement to suppress this warning that would normally occur:
switch (cond)
{
case 1:
bar (0);
__attribute__ ((fallthrough));
default:
...
}
C++17 provides a standard way to suppress the
-Wimplicit-fallthrough warning using "[[fallthrough]];"
instead of the GNU attribute. In C++11 or C++14 users can
use "[[gnu::fallthrough]];", which is a GNU extension.
Instead of these attributes, it is also possible to add a
fallthrough comment to silence the warning. The whole body
of the C or C++ style comment should match the given regular
expressions listed below. The option argument n specifies
what kind of comments are accepted:
*<-Wimplicit-fallthrough=0 disables the warning altogether.>
*<-Wimplicit-fallthrough=1 matches ".*" regular>
expression, any comment is used as fallthrough comment.
*<-Wimplicit-fallthrough=2 case insensitively matches>
".*falls?[ \t-]*thr(ough|u).*" regular expression.
*<-Wimplicit-fallthrough=3 case sensitively matches one of
the>
following regular expressions:
*<"-fallthrough">
*<"@fallthrough@">
*<"lint -fallthrough[ \t]*">
*<"[ \t.!]*(ELSE,? |INTENTIONAL(LY)? )?FALL(S |
|-)?THR(OUGH|U)[ \t.!]*(-[^\n\r]*)?">
*<"[ \t.!]*(Else,? |Intentional(ly)? )?Fall((s |
|-)[Tt]|t)hr(ough|u)[ \t.!]*(-[^\n\r]*)?">
*<"[ \t.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?fall(s |
|-)?thr(ough|u)[ \t.!]*(-[^\n\r]*)?">
*<-Wimplicit-fallthrough=4 case sensitively matches one of
the>
following regular expressions:
*<"-fallthrough">
*<"@fallthrough@">
*<"lint -fallthrough[ \t]*">
*<"[ \t]*FALLTHR(OUGH|U)[ \t]*">
*<-Wimplicit-fallthrough=5 doesn't recognize any comments as>
fallthrough comments, only attributes disable the
warning.
The comment needs to be followed after optional whitespace
and other comments by "case" or "default" keywords or by a
user label that precedes some "case" or "default" label.
switch (cond)
{
case 1:
bar (0);
/* FALLTHRU */
default:
...
}
The -Wimplicit-fallthrough=3 warning is enabled by -Wextra.
-Wif-not-aligned (C, C++, Objective-C and Objective-C++ only)
Control if warning triggered by the "warn_if_not_aligned"
attribute should be issued. This is enabled by default. Use
-Wno-if-not-aligned to disable it.
-Wignored-qualifiers (C and C++ only)
Warn if the return type of a function has a type qualifier
such as "const". For ISO C such a type qualifier has no
effect, since the value returned by a function is not an
lvalue. For C++, the warning is only emitted for scalar
types or "void". ISO C prohibits qualified "void" return
types on function definitions, so such return types always
receive a warning even without this option.
This warning is also enabled by -Wextra.
-Wignored-attributes (C and C++ only)
Warn when an attribute is ignored. This is different from
the -Wattributes option in that it warns whenever the
compiler decides to drop an attribute, not that the attribute
is either unknown, used in a wrong place, etc. This warning
is enabled by default.
-Wmain
Warn if the type of "main" is suspicious. "main" should be a
function with external linkage, returning int, taking either
zero arguments, two, or three arguments of appropriate types.
This warning is enabled by default in C++ and is enabled by
either -Wall or -Wpedantic.
-Wmisleading-indentation (C and C++ only)
Warn when the indentation of the code does not reflect the
block structure. Specifically, a warning is issued for "if",
"else", "while", and "for" clauses with a guarded statement
that does not use braces, followed by an unguarded statement
with the same indentation.
In the following example, the call to "bar" is misleadingly
indented as if it were guarded by the "if" conditional.
if (some_condition ())
foo ();
bar (); /* Gotcha: this is not guarded by the "if". */
In the case of mixed tabs and spaces, the warning uses the
-ftabstop= option to determine if the statements line up
(defaulting to 8).
The warning is not issued for code involving multiline
preprocessor logic such as the following example.
if (flagA)
foo (0);
#if SOME_CONDITION_THAT_DOES_NOT_HOLD
if (flagB)
#endif
foo (1);
The warning is not issued after a "#line" directive, since
this typically indicates autogenerated code, and no
assumptions can be made about the layout of the file that the
directive references.
This warning is enabled by -Wall in C and C++.
-Wmissing-attributes
Warn when a declaration of a function is missing one or more
attributes that a related function is declared with and whose
absence may adversely affect the correctness or efficiency of
generated code. For example, the warning is issued for
declarations of aliases that use attributes to specify less
restrictive requirements than those of their targets. This
typically represents a potential optimization opportunity.
By contrast, the -Wattribute-alias=2 option controls warnings
issued when the alias is more restrictive than the target,
which could lead to incorrect code generation. Attributes
considered include "alloc_align", "alloc_size", "cold",
"const", "hot", "leaf", "malloc", "nonnull", "noreturn",
"nothrow", "pure", "returns_nonnull", and "returns_twice".
In C++, the warning is issued when an explicit specialization
of a primary template declared with attribute "alloc_align",
"alloc_size", "assume_aligned", "format", "format_arg",
"malloc", or "nonnull" is declared without it. Attributes
"deprecated", "error", and "warning" suppress the warning..
You can use the "copy" attribute to apply the same set of
attributes to a declaration as that on another declaration
without explicitly enumerating the attributes. This attribute
can be applied to declarations of functions, variables, or
types.
-Wmissing-attributes is enabled by -Wall.
For example, since the declaration of the primary function
template below makes use of both attribute "malloc" and
"alloc_size" the declaration of the explicit specialization
of the template is diagnosed because it is missing one of the
attributes.
template <class T>
T* __attribute__ ((malloc, alloc_size (1)))
allocate (size_t);
template <>
void* __attribute__ ((malloc)) // missing alloc_size
allocate<void> (size_t);
-Wmissing-braces
Warn if an aggregate or union initializer is not fully
bracketed. In the following example, the initializer for "a"
is not fully bracketed, but that for "b" is fully bracketed.
This warning is enabled by -Wall in C.
int a[2][2] = { 0, 1, 2, 3 };
int b[2][2] = { { 0, 1 }, { 2, 3 } };
This warning is enabled by -Wall.
-Wmissing-include-dirs (C, C++, Objective-C and Objective-C++
only)
Warn if a user-supplied include directory does not exist.
-Wmissing-profile
Warn if feedback profiles are missing when using the
-fprofile-use option. This option diagnoses those cases
where a new function or a new file is added to the user code
between compiling with -fprofile-generate and with
-fprofile-use, without regenerating the profiles. In these
cases, the profile feedback data files do not contain any
profile feedback information for the newly added function or
file respectively. Also, in the case when profile count data
(.gcda) files are removed, GCC cannot use any profile
feedback information. In all these cases, warnings are
issued to inform the user that a profile generation step is
due. -Wno-missing-profile can be used to disable the
warning. Ignoring the warning can result in poorly optimized
code. Completely disabling the warning is not recommended
and should be done only when non-existent profile data is
justified.
-Wmultistatement-macros
Warn about unsafe multiple statement macros that appear to be
guarded by a clause such as "if", "else", "for", "switch", or
"while", in which only the first statement is actually
guarded after the macro is expanded.
For example:
#define DOIT x++; y++
if (c)
DOIT;
will increment "y" unconditionally, not just when "c" holds.
The can usually be fixed by wrapping the macro in a do-while
loop:
#define DOIT do { x++; y++; } while (0)
if (c)
DOIT;
This warning is enabled by -Wall in C and C++.
-Wparentheses
Warn if parentheses are omitted in certain contexts, such as
when there is an assignment in a context where a truth value
is expected, or when operators are nested whose precedence
people often get confused about.
Also warn if a comparison like "x<=y<=z" appears; this is
equivalent to "(x<=y ? 1 : 0) <= z", which is a different
interpretation from that of ordinary mathematical notation.
Also warn for dangerous uses of the GNU extension to "?:"
with omitted middle operand. When the condition in the "?":
operator is a boolean expression, the omitted value is always
1. Often programmers expect it to be a value computed inside
the conditional expression instead.
For C++ this also warns for some cases of unnecessary
parentheses in declarations, which can indicate an attempt at
a function call instead of a declaration:
{
// Declares a local variable called mymutex.
std::unique_lock<std::mutex> (mymutex);
// User meant std::unique_lock<std::mutex> lock (mymutex);
}
This warning is enabled by -Wall.
-Wsequence-point
Warn about code that may have undefined semantics because of
violations of sequence point rules in the C and C++
standards.
The C and C++ standards define the order in which expressions
in a C/C++ program are evaluated in terms of sequence points,
which represent a partial ordering between the execution of
parts of the program: those executed before the sequence
point, and those executed after it. These occur after the
evaluation of a full expression (one which is not part of a
larger expression), after the evaluation of the first operand
of a "&&", "||", "? :" or "," (comma) operator, before a
function is called (but after the evaluation of its arguments
and the expression denoting the called function), and in
certain other places. Other than as expressed by the
sequence point rules, the order of 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.
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
and C++ standards specify 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.
Examples of code with undefined behavior are "a = a++;",
"a[n] = b[n++]" and "a[i++] = i;". 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.
The C++17 standard will define the order of evaluation of
operands in more cases: in particular it requires that the
right-hand side of an assignment be evaluated before the
left-hand side, so the above examples are no longer
undefined. But this warning will still warn about them, to
help people avoid writing code that is undefined in C and
earlier revisions of C++.
The 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 the
GCC readings page, at <http://gcc.gnu.org/readings.html >.
This warning is enabled by -Wall for C and C++.
-Wno-return-local-addr
Do not warn about returning a pointer (or in C++, a
reference) to a variable that goes out of scope after the
function returns.
-Wreturn-type
Warn whenever a function is defined with a return type that
defaults to "int". Also warn about any "return" statement
with no return value in a function whose return type is not
"void" (falling off the end of the function body is
considered returning without a value).
For C only, warn about a "return" statement with an
expression in a function whose return type is "void", unless
the expression type is also "void". As a GNU extension, the
latter case is accepted without a warning unless -Wpedantic
is used. Attempting to use the return value of a non-"void"
function other than "main" that flows off the end by reaching
the closing curly brace that terminates the function is
undefined.
Unlike in C, in C++, flowing off the end of a non-"void"
function other than "main" results in undefined behavior even
when the value of the function is not used.
This warning is enabled by default in C++ and by -Wall
otherwise.
-Wshift-count-negative
Warn if shift count is negative. This warning is enabled by
default.
-Wshift-count-overflow
Warn if shift count >= width of type. This warning is enabled
by default.
-Wshift-negative-value
Warn if left shifting a negative value. This warning is
enabled by -Wextra in C99 and C++11 modes (and newer).
-Wshift-overflow
-Wshift-overflow=n
Warn about left shift overflows. This warning is enabled by
default in C99 and C++11 modes (and newer).
-Wshift-overflow=1
This is the warning level of -Wshift-overflow and is
enabled by default in C99 and C++11 modes (and newer).
This warning level does not warn about left-shifting 1
into the sign bit. (However, in C, such an overflow is
still rejected in contexts where an integer constant
expression is required.) No warning is emitted in C++2A
mode (and newer), as signed left shifts always wrap.
-Wshift-overflow=2
This warning level also warns about left-shifting 1 into
the sign bit, unless C++14 mode (or newer) is active.
-Wswitch
Warn whenever a "switch" statement has an index of enumerated
type and lacks a "case" for one or more of the named codes of
that enumeration. (The presence of a "default" label
prevents this warning.) "case" labels outside the
enumeration range also provoke warnings when this option is
used (even if there is a "default" label). This warning is
enabled by -Wall.
-Wswitch-default
Warn whenever a "switch" statement does not have a "default"
case.
-Wswitch-enum
Warn whenever a "switch" statement has an index of enumerated
type and lacks a "case" for one or more of the named codes of
that enumeration. "case" labels outside the enumeration
range also provoke warnings when this option is used. The
only difference between -Wswitch and this option is that this
option gives a warning about an omitted enumeration code even
if there is a "default" label.
-Wswitch-bool
Warn whenever a "switch" statement has an index of boolean
type and the case values are outside the range of a boolean
type. It is possible to suppress this warning by casting the
controlling expression to a type other than "bool". For
example:
switch ((int) (a == 4))
{
...
}
This warning is enabled by default for C and C++ programs.
-Wswitch-unreachable
Warn whenever a "switch" statement contains statements
between the controlling expression and the first case label,
which will never be executed. For example:
switch (cond)
{
i = 15;
...
case 5:
...
}
-Wswitch-unreachable does not warn if the statement between
the controlling expression and the first case label is just a
declaration:
switch (cond)
{
int i;
...
case 5:
i = 5;
...
}
This warning is enabled by default for C and C++ programs.
