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 -W foo . However, -Wno-error= foo does not imply anything.

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.

          -Wclobbered  
          -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)
 
          -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.

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 .

-Wnonnull is included in -Wall and -Wformat . It can be disabled with the -Wno-nonnull option.

-Wnonnull-compare is included in -Wall . It can be disabled with the -Wno-nonnull-compare 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++.

          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 the 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 .

This warning is also enabled by -Wextra .

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++.

          int a[2][2] = { 0, 1, 2, 3 };
          int b[2][2] = { { 0, 1 }, { 2, 3 } };

This warning is enabled by -Wall .

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.

This warning is enabled by -Wall .

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++.

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.

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

This warning is enabled by -Wall .

-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.)

-Wshift-overflow=2

This warning level also warns about left-shifting 1 into the sign bit, unless C++14 mode is active.

          switch ((int) (a == 4))
            {
            ...
            }

This warning is enabled by default for C and C++ programs.

          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.

This warning is enabled by -Wall .

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 .

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.

          {
            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.

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.

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.

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, with -fstrict-overflow , 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 -fstrict-overflow is in effect, 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.

-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.

          int n = 5;
          ...
          if ((n > 1) == 2) { ... }

This warning is enabled by -Wall .

This warning is enabled by -Wall .

          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;

          if (p->q != NULL) { ... }
          else if (p->q != NULL) { ... }

          int i = 1;
          ...
          if (i > i) { ... }

This warning is enabled by -Wall .

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.

• 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.

          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 .

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
  

Normally this only warns about global allocation functions, but -Waligned-new=all also warns about class member allocation functions.

          char buf [64];
          new (buf) int[64];

This warning is enabled by default.

-Wplacement-new=1

This is the default warning level of -Wplacement-new . At this level the warning is not issued for some strictly undefined constructs that GCC allows as extensions for compatibility with legacy code. For example, the following new expression is not diagnosed at this level even though it has undefined behavior according to the C++ standard because it writes past the end of the one-element array.

               struct S { int n, a[1]; };
               S *s = (S *)malloc (sizeof *s + 31 * sizeof s->a[0]);
               new (s->a)int [32]();

-Wplacement-new=2

At this level, in addition to diagnosing all the same constructs as at level 1, a diagnostic is also issued for placement new expressions that construct an object in the last member of structure whose type is an array of a single element and whose size is less than the size of the object being constructed. While the previous example would be diagnosed, the following construct makes use of the flexible member array extension to avoid the warning at level 2.

               struct S { int n, a[]; };
               S *s = (S *)malloc (sizeof *s + 32 * sizeof s->a[0]);
               new (s->a)int [32]();

          const char *p = foo ();
          if (p == '\0')
            return 42;

Note that the code above is invalid in C++11.

This warning is enabled by default.

This option is implied by -Wall . If -Wall is not given, this option is still enabled unless trigraphs are enabled. To get trigraph conversion without warnings, but get the other -Wall warnings, use ‘ -trigraphs -Wall -Wno-trigraphs ’.

Built-in macros, macros defined on the command line, and macros defined in include files are not warned about.

Note: If a macro is actually used, but only used in skipped conditional blocks, then the preprocessor reports it as unused. To avoid the warning in such a case, you might improve the scope of the macro's definition by, for example, moving it into the first skipped block. Alternatively, you could provide a dummy use with something like:

          #if defined the_macro_causing_the_warning
          #endif

          #if FOO
          ...
          #else FOO
          ...
          #endif FOO

The second and third FOO should be in comments. This warning is on by default.

Also warn when making a cast that introduces a type qualifier in an unsafe way. For example, casting char ** to const char ** is unsafe, as in this example:

            /* p is char ** value.  */
            const char **q = (const char **) p;
            /* Assignment of readonly string to const char * is OK.  */
            *q = "string";
            /* Now char** pointer points to read-only memory.  */
            **p = 'b';

When compiling C++, warn about the deprecated conversion from string literals to char * . This warning is enabled by default for C++ programs.

For C++, also warn for confusing overload resolution for user-defined conversions; and conversions that never use a type conversion operator: conversions to void , the same type, a base class or a reference to them. Warnings about conversions between signed and unsigned integers are disabled by default in C++ unless -Wsign-conversion is explicitly enabled.

          {
            if (a)
              if (b)
                foo ();
            else
              bar ();
          }

In C/C++, every else branch belongs to the innermost possible if statement, which in this example is if (b) . This is often not what the programmer expected, as illustrated in the above example by indentation the programmer chose. When there is the potential for this confusion, GCC issues a warning when this flag is specified. To eliminate the warning, add explicit braces around the innermost if statement so there is no way the else can belong to the enclosing if . The resulting code looks like this:

          {
            if (a)
              {
                if (b)
                  foo ();
                else
                  bar ();
              }
          }

This warning is enabled by -Wparentheses .

-Wjump-misses-init is included in -Wc++-compat . It can be disabled with the -Wno-jump-misses-init option.

          void operator delete (void *) noexcept;
          void operator delete[] (void *) noexcept;

without a definition of the corresponding sized deallocation function

          void operator delete (void *, std::size_t) noexcept;
          void operator delete[] (void *, std::size_t) noexcept;

or vice versa. Enabled by -Wextra along with -fsized-deallocation .

          extern int a;
          if (a < 0 && a < 0) { ... }

          int a;
          ...
          if (!a > 1) { ... }

It is possible to suppress the warning by wrapping the LHS into parentheses:

          if ((!a) > 1) { ... }

This warning is enabled by -Wall .

          void foo(bar) { }

This warning is also enabled by -Wextra .

          struct s { int f, g, h; };
          struct s x = { 3, 4 };

This option does not warn about designated initializers, so the following modification does not trigger a warning:

          struct s { int f, g, h; };
          struct s x = { .f = 3, .g = 4 };

In C++ this option does not warn either about the empty { } initializer, for example:

          struct s { int f, g, h; };
          s x = { };

This warning is included in -Wextra . To get other -Wextra warnings without this one, use -Wextra -Wno-missing-field-initializers .

There are four levels of warning supported by GCC. The default is -Wnormalized=nfc , which warns about any identifier that is not in the ISO 10646 “C” normalized form, NFC . NFC is the recommended form for most uses. It is equivalent to -Wnormalized .

Unfortunately, there are some characters allowed in identifiers by ISO C and ISO C++ that, when turned into NFC, are not allowed in identifiers. That is, there's no way to use these symbols in portable ISO C or C++ and have all your identifiers in NFC. -Wnormalized=id suppresses the warning for these characters. It is hoped that future versions of the standards involved will correct this, which is why this option is not the default.

You can switch the warning off for all characters by writing -Wnormalized=none or -Wno-normalized . You should only do this if you are using some other normalization scheme (like “D”), because otherwise you can easily create bugs that are literally impossible to see.

Some characters in ISO 10646 have distinct meanings but look identical in some fonts or display methodologies, especially once formatting has been applied. For instance \u207F , “SUPERSCRIPT LATIN SMALL LETTER N”, displays just like a regular n that has been placed in a superscript. ISO 10646 defines the NFKC normalization scheme to convert all these into a standard form as well, and GCC warns if your code is not in NFKC if you use -Wnormalized=nfkc . This warning is comparable to warning about every identifier that contains the letter O because it might be confused with the digit 0, and so is not the default, but may be useful as a local coding convention if the programming environment cannot be fixed to display these characters distinctly.

          struct foo {
            int x;
            char a, b, c, d;
          } __attribute__((packed));
          struct bar {
            char z;
            struct foo f;
          };

          struct foo
          {
            char a:4;
            char b:8;
          } __attribute__ ((packed));

This warning is enabled by default. Use -Wno-packed-bitfield-compat to disable this warning.

The compiler uses a variety of heuristics to determine whether or not to inline a function. For example, the compiler takes into account the size of the function being inlined and the amount of inlining that has already been done in the current function. Therefore, seemingly insignificant changes in the source program can cause the warnings produced by -Winline to appear or disappear.

The restrictions on offsetof may be relaxed in a future version of the C++ standard.

The limit applies after string constant concatenation, and does not count the trailing NUL. In C90, the limit was 509 characters; in C99, it was raised to 4095. C++98 does not specify a normative minimum maximum, so we do not diagnose overlength strings in C++.

This option is implied by -Wpedantic , and can be disabled with -Wno-overlength-strings .