компилятор C и C ++ проекта GNU (GNU project C and C++ compiler)
Параметры подробно (Options detail)
Request or Suppress Warnings - 2
-Wsync-nand (C and C++ only)
Warn when "__sync_fetch_and_nand" and "__sync_nand_and_fetch"
built-in functions are used. These functions changed
semantics in GCC 4.4.
-Wunused-but-set-parameter
Warn whenever a function parameter is assigned to, but
otherwise unused (aside from its declaration).
To suppress this warning use the "unused" attribute.
This warning is also enabled by -Wunused together with
-Wextra.
-Wunused-but-set-variable
Warn whenever a local variable is assigned to, but otherwise
unused (aside from its declaration). This warning is enabled
by -Wall.
To suppress this warning use the "unused" attribute.
This warning is also enabled by -Wunused, which is enabled by
-Wall.
-Wunused-function
Warn whenever a static function is declared but not defined
or a non-inline static function is unused. This warning is
enabled by -Wall.
-Wunused-label
Warn whenever a label is declared but not used. This warning
is enabled by -Wall.
To suppress this warning use the "unused" attribute.
-Wunused-local-typedefs (C, Objective-C, C++ and Objective-C++
only)
Warn when a typedef locally defined in a function is not
used. This warning is enabled by -Wall.
-Wunused-parameter
Warn whenever a function parameter is unused aside from its
declaration.
To suppress this warning use the "unused" attribute.
-Wno-unused-result
Do not warn if a caller of a function marked with attribute
"warn_unused_result" does not use its return value. The
default is -Wunused-result.
-Wunused-variable
Warn whenever a local or static variable is unused aside from
its declaration. This option implies
-Wunused-const-variable=1 for C, but not for C++. This
warning is enabled by -Wall.
To suppress this warning use the "unused" attribute.
-Wunused-const-variable
-Wunused-const-variable=n
Warn whenever a constant static variable is unused aside from
its declaration. -Wunused-const-variable=1 is enabled by
-Wunused-variable for C, but not for C++. In C this declares
variable storage, but in C++ this is not an error since const
variables take the place of "#define"s.
To suppress this warning use the "unused" attribute.
-Wunused-const-variable=1
This is the warning level that is enabled by
-Wunused-variable for C. It warns only about unused
static const variables defined in the main compilation
unit, but not about static const variables declared in
any header included.
-Wunused-const-variable=2
This warning level also warns for unused constant static
variables in headers (excluding system headers). This is
the warning level of -Wunused-const-variable and must be
explicitly requested since in C++ this isn't an error and
in C it might be harder to clean up all headers included.
-Wunused-value
Warn whenever a statement computes a result that is
explicitly not used. To suppress this warning cast the unused
expression to "void". This includes an expression-statement
or the left-hand side of a comma expression that contains no
side effects. For example, an expression such as "x[i,j]"
causes a warning, while "x[(void)i,j]" does not.
This warning is enabled by -Wall.
-Wunused
All the above -Wunused options combined.
In order to get a warning about an unused function parameter,
you must either specify -Wextra -Wunused (note that -Wall
implies -Wunused), or separately specify -Wunused-parameter.
-Wuninitialized
Warn if an automatic variable is used without first being
initialized or if a variable may be clobbered by a "setjmp"
call. In C++, warn if a non-static reference or non-static
"const" member appears in a class without constructors.
If you want to warn about code that uses the uninitialized
value of the variable in its own initializer, use the
-Winit-self option.
These warnings occur for individual uninitialized or
clobbered elements of structure, union or array variables as
well as for variables that are uninitialized or clobbered as
a whole. They do not occur for variables or elements
declared "volatile". Because these warnings depend on
optimization, the exact variables or elements for which there
are warnings depends on the precise optimization options and
version of GCC used.
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.
-Winvalid-memory-model
Warn for invocations of __atomic Builtins, __sync Builtins,
and the C11 atomic generic functions with a memory
consistency argument that is either invalid for the operation
or outside the range of values of the "memory_order"
enumeration. For example, since the "__atomic_store" and
"__atomic_store_n" built-ins are only defined for the
relaxed, release, and sequentially consistent memory orders
the following code is diagnosed:
void store (int *i)
{
__atomic_store_n (i, 0, memory_order_consume);
}
-Winvalid-memory-model is enabled by default.
-Wmaybe-uninitialized
For an automatic (i.e. local) variable, if there exists a
path from the function entry to a use of the variable that is
initialized, but there exist some other paths for which the
variable is not initialized, the compiler emits a warning if
it cannot prove the uninitialized paths are not executed at
run time.
These warnings are only possible in optimizing compilation,
because otherwise GCC does not keep track of the state of
variables.
These warnings are made optional because GCC may not be able
to determine when the code is correct in spite of appearing
to have an error. Here is one example of how this can
happen:
{
int x;
switch (y)
{
case 1: x = 1;
break;
case 2: x = 4;
break;
case 3: x = 5;
}
foo (x);
}
If the value of "y" is always 1, 2 or 3, then "x" is always
initialized, but GCC doesn't know this. To suppress the
warning, you need to provide a default case with assert(0) or
similar code.
This option also warns when a non-volatile automatic variable
might be changed by a call to "longjmp". The compiler sees
only the calls to "setjmp". It cannot know where "longjmp"
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 "longjmp"
cannot in fact be called at the place that would cause a
problem.
Some spurious warnings can be avoided if you declare all the
functions you use that never return as "noreturn".
This warning is enabled by -Wall or -Wextra.
-Wunknown-pragmas
Warn when a "#pragma" directive is encountered that is not
understood by GCC. If this command-line option is used,
warnings are even issued for unknown pragmas in system header
files. This is not the case if the warnings are only enabled
by the -Wall command-line option.
-Wno-pragmas
Do not warn about misuses of pragmas, such as incorrect
parameters, invalid syntax, or conflicts between pragmas.
See also -Wunknown-pragmas.
-Wno-prio-ctor-dtor
Do not warn if a priority from 0 to 100 is used for
constructor or destructor. The use of constructor and
destructor attributes allow you to assign a priority to the
constructor/destructor to control its order of execution
before "main" is called or after it returns. The priority
values must be greater than 100 as the compiler reserves
priority values between 0--100 for the implementation.
-Wstrict-aliasing
This option is only active when -fstrict-aliasing is active.
It warns about code that 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 -Wall. It is
equivalent to -Wstrict-aliasing=3
-Wstrict-aliasing=n
This option is only active when -fstrict-aliasing is active.
It warns about code that might break the strict aliasing
rules that the compiler is using for optimization. Higher
levels correspond to higher accuracy (fewer false positives).
Higher levels also correspond to more effort, similar to the
way -O works. -Wstrict-aliasing is equivalent to
-Wstrict-aliasing=3.
Level 1: Most aggressive, quick, least accurate. Possibly
useful when higher levels do not warn but -fstrict-aliasing
still breaks the code, as it has very few false negatives.
However, it has many false positives. Warns for all pointer
conversions between possibly incompatible types, even if
never dereferenced. Runs in the front end only.
Level 2: Aggressive, quick, not too precise. May still have
many false positives (not as many as level 1 though), and few
false negatives (but possibly more than level 1). Unlike
level 1, it only warns when an address is taken. Warns about
incomplete types. Runs in the front end only.
Level 3 (default for -Wstrict-aliasing): Should have very few
false positives and few false negatives. Slightly slower
than levels 1 or 2 when optimization is enabled. Takes care
of the common pun+dereference pattern in the front end:
"*(int*)&some_float". If optimization is enabled, it also
runs in the back end, where it deals with multiple statement
cases using flow-sensitive points-to information. Only warns
when the converted pointer is dereferenced. Does not warn
about incomplete types.
-Wstrict-overflow
-Wstrict-overflow=n
This option is only active when signed overflow is undefined.
It warns about cases where the compiler optimizes based on
the assumption that signed overflow does not occur. Note
that it does not warn about all cases where the code might
overflow: it only warns about cases where the compiler
implements some optimization. Thus this warning depends on
the optimization level.
An optimization that assumes that signed overflow does not
occur is perfectly safe if the values of the variables
involved are such that overflow never does, in fact, occur.
Therefore this warning can easily give a false positive: a
warning about code that is not actually a problem. To help
focus on important issues, several warning levels are
defined. No warnings are issued for the use of undefined
signed overflow when estimating how many iterations a loop
requires, in particular when determining whether a loop will
be executed at all.
-Wstrict-overflow=1
Warn about cases that are both questionable and easy to
avoid. For example the compiler simplifies "x + 1 > x"
to 1. This level of -Wstrict-overflow is enabled by
-Wall; higher levels are not, and must be explicitly
requested.
-Wstrict-overflow=2
Also warn about other cases where a comparison is
simplified to a constant. For example: "abs (x) >= 0".
This can only be simplified when signed integer overflow
is undefined, because "abs (INT_MIN)" overflows to
"INT_MIN", which is less than zero. -Wstrict-overflow
(with no level) is the same as -Wstrict-overflow=2.
-Wstrict-overflow=3
Also warn about other cases where a comparison is
simplified. For example: "x + 1 > 1" is simplified to "x
> 0".
-Wstrict-overflow=4
Also warn about other simplifications not covered by the
above cases. For example: "(x * 10) / 5" is simplified
to "x * 2".
-Wstrict-overflow=5
Also warn about cases where the compiler reduces the
magnitude of a constant involved in a comparison. For
example: "x + 2 > y" is simplified to "x + 1 >= y". This
is reported only at the highest warning level because
this simplification applies to many comparisons, so this
warning level gives a very large number of false
positives.
-Wstringop-overflow
-Wstringop-overflow=type
Warn for calls to string manipulation functions such as
"memcpy" and "strcpy" that are determined to overflow the
destination buffer. The optional argument is one greater
than the type of Object Size Checking to perform to determine
the size of the destination. The argument is meaningful only
for functions that operate on character arrays but not for
raw memory functions like "memcpy" which always make use of
Object Size type-0. The option also warns for calls that
specify a size in excess of the largest possible object or at
most "SIZE_MAX / 2" bytes. The option produces the best
results with optimization enabled but can detect a small
subset of simple buffer overflows even without optimization
in calls to the GCC built-in functions like
"__builtin_memcpy" that correspond to the standard functions.
In any case, the option warns about just a subset of buffer
overflows detected by the corresponding overflow checking
built-ins. For example, the option will issue a warning for
the "strcpy" call below because it copies at least 5
characters (the string "blue" including the terminating NUL)
into the buffer of size 4.
enum Color { blue, purple, yellow };
const char* f (enum Color clr)
{
static char buf [4];
const char *str;
switch (clr)
{
case blue: str = "blue"; break;
case purple: str = "purple"; break;
case yellow: str = "yellow"; break;
}
return strcpy (buf, str); // warning here
}
Option -Wstringop-overflow=2 is enabled by default.
-Wstringop-overflow
-Wstringop-overflow=1
The -Wstringop-overflow=1 option uses type-zero Object
Size Checking to determine the sizes of destination
objects. This is the default setting of the option. At
this setting the option will not warn for writes past the
end of subobjects of larger objects accessed by pointers
unless the size of the largest surrounding object is
known. When the destination may be one of several
objects it is assumed to be the largest one of them. On
Linux systems, when optimization is enabled at this
setting the option warns for the same code as when the
"_FORTIFY_SOURCE" macro is defined to a non-zero value.
-Wstringop-overflow=2
The -Wstringop-overflow=2 option uses type-one Object
Size Checking to determine the sizes of destination
objects. At this setting the option will warn about
overflows when writing to members of the largest complete
objects whose exact size is known. It will, however, not
warn for excessive writes to the same members of unknown
objects referenced by pointers since they may point to
arrays containing unknown numbers of elements.
-Wstringop-overflow=3
The -Wstringop-overflow=3 option uses type-two Object
Size Checking to determine the sizes of destination
objects. At this setting the option warns about
overflowing the smallest object or data member. This is
the most restrictive setting of the option that may
result in warnings for safe code.
-Wstringop-overflow=4
The -Wstringop-overflow=4 option uses type-three Object
Size Checking to determine the sizes of destination
objects. At this setting the option will warn about
overflowing any data members, and when the destination is
one of several objects it uses the size of the largest of
them to decide whether to issue a warning. Similarly to
-Wstringop-overflow=3 this setting of the option may
result in warnings for benign code.
-Wstringop-truncation
Warn for calls to bounded string manipulation functions such
as "strncat", "strncpy", and "stpncpy" that may either
truncate the copied string or leave the destination
unchanged.
In the following example, the call to "strncat" specifies a
bound that is less than the length of the source string. As
a result, the copy of the source will be truncated and so the
call is diagnosed. To avoid the warning use "bufsize -
strlen (buf) - 1)" as the bound.
void append (char *buf, size_t bufsize)
{
strncat (buf, ".txt", 3);
}
As another example, the following call to "strncpy" results
in copying to "d" just the characters preceding the
terminating NUL, without appending the NUL to the end.
Assuming the result of "strncpy" is necessarily a NUL-
terminated string is a common mistake, and so the call is
diagnosed. To avoid the warning when the result is not
expected to be NUL-terminated, call "memcpy" instead.
void copy (char *d, const char *s)
{
strncpy (d, s, strlen (s));
}
In the following example, the call to "strncpy" specifies the
size of the destination buffer as the bound. If the length
of the source string is equal to or greater than this size
the result of the copy will not be NUL-terminated.
Therefore, the call is also diagnosed. To avoid the warning,
specify "sizeof buf - 1" as the bound and set the last
element of the buffer to "NUL".
void copy (const char *s)
{
char buf[80];
strncpy (buf, s, sizeof buf);
...
}
In situations where a character array is intended to store a
sequence of bytes with no terminating "NUL" such an array may
be annotated with attribute "nonstring" to avoid this
warning. Such arrays, however, are not suitable arguments to
functions that expect "NUL"-terminated strings. To help
detect accidental misuses of such arrays GCC issues warnings
unless it can prove that the use is safe.
-Wsuggest-attribute=[pure|const|noreturn|format|cold|malloc]
Warn for cases where adding an attribute may be beneficial.
The attributes currently supported are listed below.
-Wsuggest-attribute=pure
-Wsuggest-attribute=const
-Wsuggest-attribute=noreturn
-Wmissing-noreturn
-Wsuggest-attribute=malloc
Warn about functions that might be candidates for
attributes "pure", "const" or "noreturn" or "malloc". The
compiler only warns for functions visible in other
compilation units or (in the case of "pure" and "const")
if it cannot prove that the function returns normally. A
function returns normally if it doesn't contain an
infinite loop or return abnormally by throwing, calling
"abort" or trapping. This analysis requires option
-fipa-pure-const, which is enabled by default at -O and
higher. Higher optimization levels improve the accuracy
of the analysis.
-Wsuggest-attribute=format
-Wmissing-format-attribute
Warn about function pointers that might be candidates for
"format" attributes. Note these are only possible
candidates, not absolute ones. GCC guesses that function
pointers with "format" attributes that are used in
assignment, initialization, parameter passing or return
statements should have a corresponding "format" attribute
in the resulting type. I.e. the left-hand side of the
assignment or initialization, the type of the parameter
variable, or the return type of the containing function
respectively should also have a "format" attribute to
avoid the warning.
GCC also warns about function definitions that might be
candidates for "format" attributes. Again, these are
only possible candidates. GCC guesses that "format"
attributes might be appropriate for any function that
calls a function like "vprintf" or "vscanf", but this
might not always be the case, and some functions for
which "format" attributes are appropriate may not be
detected.
-Wsuggest-attribute=cold
Warn about functions that might be candidates for "cold"
attribute. This is based on static detection and
generally will only warn about functions which always
leads to a call to another "cold" function such as
wrappers of C++ "throw" or fatal error reporting
functions leading to "abort".
-Wsuggest-final-types
Warn about types with virtual methods where code quality
would be improved if the type were declared with the C++11
"final" specifier, or, if possible, declared in an anonymous
namespace. This allows GCC to more aggressively devirtualize
the polymorphic calls. This warning is more effective with
link time optimization, where the information about the class
hierarchy graph is more complete.
-Wsuggest-final-methods
Warn about virtual methods where code quality would be
improved if the method were declared with the C++11 "final"
specifier, or, if possible, its type were declared in an
anonymous namespace or with the "final" specifier. This
warning is more effective with link-time optimization, where
the information about the class hierarchy graph is more
complete. It is recommended to first consider suggestions of
-Wsuggest-final-types and then rebuild with new annotations.
-Wsuggest-override
Warn about overriding virtual functions that are not marked
with the override keyword.
-Walloc-zero
Warn about calls to allocation functions decorated with
attribute "alloc_size" that specify zero bytes, including
those to the built-in forms of the functions "aligned_alloc",
"alloca", "calloc", "malloc", and "realloc". Because the
behavior of these functions when called with a zero size
differs among implementations (and in the case of "realloc"
has been deprecated) relying on it may result in subtle
portability bugs and should be avoided.
-Walloc-size-larger-than=byte-size
Warn about calls to functions decorated with attribute
"alloc_size" that attempt to allocate objects larger than the
specified number of bytes, or where the result of the size
computation in an integer type with infinite precision would
exceed the value of PTRDIFF_MAX on the target.
-Walloc-size-larger-than=PTRDIFF_MAX is enabled by default.
Warnings controlled by the option can be disabled either by
specifying byte-size of SIZE_MAX or more or by
-Wno-alloc-size-larger-than.
-Wno-alloc-size-larger-than
Disable -Walloc-size-larger-than= warnings. The option is
equivalent to -Walloc-size-larger-than=SIZE_MAX or larger.
-Walloca
This option warns on all uses of "alloca" in the source.
-Walloca-larger-than=byte-size
This option warns on calls to "alloca" with an integer
argument whose value is either zero, or that is not bounded
by a controlling predicate that limits its value to at most
byte-size. It also warns for calls to "alloca" where the
bound value is unknown. Arguments of non-integer types are
considered unbounded even if they appear to be constrained to
the expected range.
For example, a bounded case of "alloca" could be:
void func (size_t n)
{
void *p;
if (n <= 1000)
p = alloca (n);
else
p = malloc (n);
f (p);
}
In the above example, passing "-Walloca-larger-than=1000"
would not issue a warning because the call to "alloca" is
known to be at most 1000 bytes. However, if
"-Walloca-larger-than=500" were passed, the compiler would
emit a warning.
Unbounded uses, on the other hand, are uses of "alloca" with
no controlling predicate constraining its integer argument.
For example:
void func ()
{
void *p = alloca (n);
f (p);
}
If "-Walloca-larger-than=500" were passed, the above would
trigger a warning, but this time because of the lack of
bounds checking.
Note, that even seemingly correct code involving signed
integers could cause a warning:
void func (signed int n)
{
if (n < 500)
{
p = alloca (n);
f (p);
}
}
In the above example, n could be negative, causing a larger
than expected argument to be implicitly cast into the
"alloca" call.
This option also warns when "alloca" is used in a loop.
-Walloca-larger-than=PTRDIFF_MAX is enabled by default but is
usually only effective when -ftree-vrp is active (default
for -O2 and above).
See also -Wvla-larger-than=byte-size.
-Wno-alloca-larger-than
Disable -Walloca-larger-than= warnings. The option is
equivalent to -Walloca-larger-than=SIZE_MAX or larger.
-Warray-bounds
-Warray-bounds=n
This option is only active when -ftree-vrp is active (default
for -O2 and above). It warns about subscripts to arrays that
are always out of bounds. This warning is enabled by -Wall.
-Warray-bounds=1
This is the warning level of -Warray-bounds and is
enabled by -Wall; higher levels are not, and must be
explicitly requested.
-Warray-bounds=2
This warning level also warns about out of bounds access
for arrays at the end of a struct and for arrays accessed
through pointers. This warning level may give a larger
number of false positives and is deactivated by default.
-Wattribute-alias=n
-Wno-attribute-alias
Warn about declarations using the "alias" and similar
attributes whose target is incompatible with the type of the
alias.
-Wattribute-alias=1
The default warning level of the -Wattribute-alias option
diagnoses incompatibilities between the type of the alias
declaration and that of its target. Such
incompatibilities are typically indicative of bugs.
-Wattribute-alias=2
At this level -Wattribute-alias also diagnoses cases
where the attributes of the alias declaration are more
restrictive than the attributes applied to its target.
These mismatches can potentially result in incorrect code
generation. In other cases they may be benign and could
be resolved simply by adding the missing attribute to the
target. For comparison, see the -Wmissing-attributes
option, which controls diagnostics when the alias
declaration is less restrictive than the target, rather
than more restrictive.
Attributes considered include "alloc_align",
"alloc_size", "cold", "const", "hot", "leaf", "malloc",
"nonnull", "noreturn", "nothrow", "pure",
"returns_nonnull", and "returns_twice".
-Wattribute-alias is equivalent to -Wattribute-alias=1. This
is the default. You can disable these warnings with either
-Wno-attribute-alias or -Wattribute-alias=0.
-Wbool-compare
Warn about boolean expression compared with an integer value
different from "true"/"false". For instance, the following
comparison is always false:
int n = 5;
...
if ((n > 1) == 2) { ... }
This warning is enabled by -Wall.
-Wbool-operation
Warn about suspicious operations on expressions of a boolean
type. For instance, bitwise negation of a boolean is very
likely a bug in the program. For C, this warning also warns
about incrementing or decrementing a boolean, which rarely
makes sense. (In C++, decrementing a boolean is always
invalid. Incrementing a boolean is invalid in C++17, and
deprecated otherwise.)
This warning is enabled by -Wall.
-Wduplicated-branches
Warn when an if-else has identical branches. This warning
detects cases like
if (p != NULL)
return 0;
else
return 0;
It doesn't warn when both branches contain just a null
statement. This warning also warn for conditional operators:
int i = x ? *p : *p;
-Wduplicated-cond
Warn about duplicated conditions in an if-else-if chain. For
instance, warn for the following code:
if (p->q != NULL) { ... }
else if (p->q != NULL) { ... }
-Wframe-address
Warn when the __builtin_frame_address or
__builtin_return_address is called with an argument greater
than 0. Such calls may return indeterminate values or crash
the program. The warning is included in -Wall.
-Wno-discarded-qualifiers (C and Objective-C only)
Do not warn if type qualifiers on pointers are being
discarded. Typically, the compiler warns if a "const char *"
variable is passed to a function that takes a "char *"
parameter. This option can be used to suppress such a
warning.
-Wno-discarded-array-qualifiers (C and Objective-C only)
Do not warn if type qualifiers on arrays which are pointer
targets are being discarded. Typically, the compiler warns if
a "const int (*)[]" variable is passed to a function that
takes a "int (*)[]" parameter. This option can be used to
suppress such a warning.
-Wno-incompatible-pointer-types (C and Objective-C only)
Do not warn when there is a conversion between pointers that
have incompatible types. This warning is for cases not
covered by -Wno-pointer-sign, which warns for pointer
argument passing or assignment with different signedness.
-Wno-int-conversion (C and Objective-C only)
Do not warn about incompatible integer to pointer and pointer
to integer conversions. This warning is about implicit
conversions; for explicit conversions the warnings
-Wno-int-to-pointer-cast and -Wno-pointer-to-int-cast may be
used.
-Wno-div-by-zero
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.
-Wsystem-headers
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 -Wall in conjunction with
this option does not warn about unknown pragmas in system
headers---for that, -Wunknown-pragmas must also be used.
-Wtautological-compare
Warn if a self-comparison always evaluates to true or false.
This warning detects various mistakes such as:
int i = 1;
...
if (i > i) { ... }
This warning also warns about bitwise comparisons that always
evaluate to true or false, for instance:
if ((a & 16) == 10) { ... }
will always be false.
This warning is enabled by -Wall.
-Wtrampolines
Warn about trampolines generated for pointers to nested
functions. A trampoline is a small piece of data or code
that is created at run time on the stack when the address of
a nested function is taken, and is used to call the nested
function indirectly. For some targets, it is made up of data
only and thus requires no special treatment. But, for most
targets, it is made up of code and thus requires the stack to
be made executable in order for the program to work properly.
-Wfloat-equal
Warn if floating-point values are used in equality
comparisons.
The idea behind this is that sometimes it is convenient (for
the programmer) to consider floating-point values as
approximations to infinitely precise real numbers. If you
are doing this, then you need to compute (by analyzing the
code, or in some other way) the maximum or likely maximum
error that the computation introduces, and allow for it when
performing comparisons (and when producing output, but that's
a different problem). In particular, instead of testing for
equality, you should check to see whether the two values have
ranges that overlap; and this is done with the relational
operators, so equality comparisons are probably mistaken.
-Wtraditional (C and Objective-C only)
Warn about certain constructs that behave differently in
traditional and ISO C. Also warn about ISO C constructs that
have no traditional C equivalent, and/or problematic
constructs that should be avoided.
* Macro parameters that appear within string literals in
the macro body. In traditional C macro replacement takes
place within string literals, but in ISO C it does not.
* In traditional C, some preprocessor directives did not
exist. Traditional preprocessors only considered a line
to be a directive if the # appeared in column 1 on the
line. Therefore -Wtraditional warns about directives
that traditional C understands but ignores because the #
does not appear as the first character on the line. It
also suggests you hide directives like "#pragma" not
understood by traditional C by indenting them. Some
traditional implementations do not recognize "#elif", so
this option suggests avoiding it altogether.
* A function-like macro that appears without arguments.
* The unary plus operator.
* The U integer constant suffix, or the F or L floating-
point constant suffixes. (Traditional C does support the
L suffix on integer constants.) Note, these suffixes
appear in macros defined in the system headers of most
modern systems, e.g. the _MIN/_MAX macros in
"<limits.h>". Use of these macros in user code might
normally lead to spurious warnings, however GCC's
integrated preprocessor has enough context to avoid
warning in these cases.
* A function declared external in one block and then used
after the end of the block.
* A "switch" statement has an operand of type "long".
* A non-"static" function declaration follows a "static"
one. This construct is not accepted by some traditional
C compilers.
* The ISO type of an integer constant has a different width
or signedness from its traditional type. This warning is
only issued if the base of the constant is ten. I.e.
hexadecimal or octal values, which typically represent
bit patterns, are not warned about.
* Usage of ISO string concatenation is detected.
* Initialization of automatic aggregates.
* Identifier conflicts with labels. Traditional C lacks a
separate namespace for labels.
* Initialization of unions. If the initializer is zero,
the warning is omitted. This is done under the
assumption that the zero initializer in user code appears
conditioned on e.g. "__STDC__" to avoid missing
initializer warnings and relies on default initialization
to zero in the traditional C case.
* Conversions by prototypes between fixed/floating-point
values and vice versa. The absence of these prototypes
when compiling with traditional C causes serious
problems. This is a subset of the possible conversion
warnings; for the full set use -Wtraditional-conversion.
* Use of ISO C style function definitions. This warning
intentionally is not issued for prototype declarations or
variadic functions because these ISO C features appear in
your code when using libiberty's traditional C
compatibility macros, "PARAMS" and "VPARAMS". This
warning is also bypassed for nested functions because
that feature is already a GCC extension and thus not
relevant to traditional C compatibility.
-Wtraditional-conversion (C and Objective-C only)
Warn if a prototype causes a type conversion that is
different from what would happen to the same argument in the
absence of a prototype. This includes conversions of fixed
point to floating and vice versa, and conversions changing
the width or signedness of a fixed-point argument except when
the same as the default promotion.
-Wdeclaration-after-statement (C and Objective-C only)
Warn when a declaration is found after a statement in a
block. This construct, known from C++, was introduced with
ISO C99 and is by default allowed in GCC. It is not
supported by ISO C90.
-Wshadow
Warn whenever a local variable or type declaration shadows
another variable, parameter, type, class member (in C++), or
instance variable (in Objective-C) or whenever a built-in
function is shadowed. Note that in C++, the compiler warns if
a local variable shadows an explicit typedef, but not if it
shadows a struct/class/enum. Same as -Wshadow=global.
-Wno-shadow-ivar (Objective-C only)
Do not warn whenever a local variable shadows an instance
variable in an Objective-C method.
-Wshadow=global
The default for -Wshadow. Warns for any (global) shadowing.
-Wshadow=local
Warn when a local variable shadows another local variable or
parameter. This warning is enabled by -Wshadow=global.
-Wshadow=compatible-local
Warn when a local variable shadows another local variable or
parameter whose type is compatible with that of the shadowing
variable. In C++, type compatibility here means the type of
the shadowing variable can be converted to that of the
shadowed variable. The creation of this flag (in addition to
-Wshadow=local) is based on the idea that when a local
variable shadows another one of incompatible type, it is most
likely intentional, not a bug or typo, as shown in the
following example:
for (SomeIterator i = SomeObj.begin(); i != SomeObj.end(); ++i)
{
for (int i = 0; i < N; ++i)
{
...
}
...
}
Since the two variable "i" in the example above have
incompatible types, enabling only -Wshadow=compatible-local
will not emit a warning. Because their types are
incompatible, if a programmer accidentally uses one in place
of the other, type checking will catch that and emit an error
or warning. So not warning (about shadowing) in this case
will not lead to undetected bugs. Use of this flag instead of
-Wshadow=local can possibly reduce the number of warnings
triggered by intentional shadowing.
This warning is enabled by -Wshadow=local.
-Wlarger-than=byte-size
Warn whenever an object is defined whose size exceeds byte-
size. -Wlarger-than=PTRDIFF_MAX is enabled by default.
Warnings controlled by the option can be disabled either by
specifying byte-size of SIZE_MAX or more or by
-Wno-larger-than.
-Wno-larger-than
Disable -Wlarger-than= warnings. The option is equivalent to
-Wlarger-than=SIZE_MAX or larger.
-Wframe-larger-than=byte-size
Warn if the size of a function frame exceeds byte-size. The
computation done to determine the stack frame size is
approximate and not conservative. The actual requirements
may be somewhat greater than byte-size even if you do not get
a warning. In addition, any space allocated via "alloca",
variable-length arrays, or related constructs is not included
by the compiler when determining whether or not to issue a
warning. -Wframe-larger-than=PTRDIFF_MAX is enabled by
default. Warnings controlled by the option can be disabled
either by specifying byte-size of SIZE_MAX or more or by
-Wno-frame-larger-than.
-Wno-frame-larger-than
Disable -Wframe-larger-than= warnings. The option is
equivalent to -Wframe-larger-than=SIZE_MAX or larger.
-Wno-free-nonheap-object
Do not warn when attempting to free an object that was not
allocated on the heap.
-Wstack-usage=byte-size
Warn if the stack usage of a function might exceed byte-size.
The computation done to determine the stack usage is
conservative. Any space allocated via "alloca", variable-
length arrays, or related constructs is included by the
compiler when determining whether or not to issue a warning.
The message is in keeping with the output of -fstack-usage.
* If the stack usage is fully static but exceeds the
specified amount, it's:
warning: stack usage is 1120 bytes
* If the stack usage is (partly) dynamic but bounded, it's:
warning: stack usage might be 1648 bytes
* If the stack usage is (partly) dynamic and not bounded,
it's:
warning: stack usage might be unbounded
-Wstack-usage=PTRDIFF_MAX is enabled by default. Warnings
controlled by the option can be disabled either by specifying
byte-size of SIZE_MAX or more or by -Wno-stack-usage.
-Wno-stack-usage
Disable -Wstack-usage= warnings. The option is equivalent to
-Wstack-usage=SIZE_MAX or larger.
