neulab/tldr huggingface dataset:
-Wold-style-declaration (C and Objective-C only) Warn for obsolescent usages, according to the C Standard, in a declaration. For example, warn if storage-class specifiers like "static" are not the first things in a declaration.  This warning is also enabled by -Wextra.
-Wold-style-definition (C and Objective-C only) Warn if an old-style function definition is used.  A warning is given even if there is a previous prototype.  A definition using () is not considered an old-style definition in C2X mode, because it is equivalent to (void) in that case, but is considered an old-style definition for older standards.
-Wmissing-parameter-type (C and Objective-C only) A function parameter is declared without a type specifier in K&R-style functions:
void foo(bar) { }
-Wmissing-prototypes (C and Objective-C only) Warn if a global function is defined without a previous prototype declaration.  This warning is issued even if the definition itself provides a prototype.  Use this option to detect global functions that do not have a matching prototype declaration in a header file. This option is not valid for C++ because all function declarations provide prototypes and a non-matching declaration declares an overload rather than conflict with an earlier declaration.  Use -Wmissing-declarations to detect missing declarations in C++.
-Wmissing-declarations Warn if a global function is defined without a previous declaration. Do so even if the definition itself provides a prototype.  Use this option to detect global functions that are not declared in header files.  In C, no warnings are issued for functions with previous non- prototype declarations; use -Wmissing-prototypes to detect missing prototypes.  In C++, no warnings are issued for function templates, or for inline functions, or for functions in anonymous namespaces.
-Wmissing-field-initializers Warn if a structure's initializer has some fields missing.  For example, the following code causes such a warning, because "x.h" is implicitly zero:
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 about the universal zero initializer { 0 }:
struct s { int f, g, h; }; struct s x = { 0 };
Likewise, in C++ this option does not warn 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.
-Wno-multichar Do not warn if a multicharacter constant ('FOOF') is used.  Usually they indicate a typo in the user's code, as they have implementation- defined values, and should not be used in portable code.
-Wnormalized=[none|id|nfc|nfkc] In ISO C and ISO C++, two identifiers are different if they are different sequences of characters.  However, sometimes when characters outside the basic ASCII character set are used, you can have two different character sequences that look the same.  To avoid confusion, the ISO 10646 standard sets out some normalization rules which when applied ensure that two sequences that look the same are turned into the same sequence.  GCC can warn you if you are using identifiers that have not been normalized; this option controls that warning.
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.
-Wno-attribute-warning Do not warn about usage of functions declared with "warning" attribute.  By default, this warning is enabled. -Wno-attribute-warning can be used to disable the warning or -Wno-error=attribute-warning can be used to disable the error when compiled with -Werror flag.
-Wno-deprecated Do not warn about usage of deprecated features.
-Wno-deprecated-declarations Do not warn about uses of functions, variables, and types marked as deprecated by using the "deprecated" attribute.
-Wno-overflow Do not warn about compile-time overflow in constant expressions.
-Wno-odr Warn about One Definition Rule violations during link-time optimization.  Enabled by default.
-Wopenmp-simd Warn if the vectorizer cost model overrides the OpenMP simd directive set by user.  The -fsimd-cost-model=unlimited option can be used to relax the cost model.
-Woverride-init (C and Objective-C only) Warn if an initialized field without side effects is overridden when using designated initializers.
This warning is included in -Wextra.  To get other -Wextra warnings without this one, use -Wextra -Wno-override-init.
-Wno-override-init-side-effects (C and Objective-C only) Do not warn if an initialized field with side effects is overridden when using designated initializers.  This warning is enabled by default.
-Wpacked Warn if a structure is given the packed attribute, but the packed attribute has no effect on the layout or size of the structure.  Such structures may be mis-aligned for little benefit.  For instance, in this code, the variable "f.x" in "struct bar" is misaligned even though "struct bar" does not itself have the packed attribute:
struct foo { int x; char a, b, c, d; } __attribute__((packed)); struct bar { char z; struct foo f; };
-Wnopacked-bitfield-compat The 4.1, 4.2 and 4.3 series of GCC ignore the "packed" attribute on bit-fields of type "char".  This was fixed in GCC 4.4 but the change can lead to differences in the structure layout.  GCC informs you when the offset of such a field has changed in GCC 4.4.  For example there is no longer a 4-bit padding between field "a" and "b" in this structure:
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.
-Wpacked-not-aligned (C, C++, Objective-C and Objective-C++ only) Warn if a structure field with explicitly specified alignment in a packed struct or union is misaligned.  For example, a warning will be issued on "struct S", like, "warning: alignment 1 of 'struct S' is less than 8", in this code:
struct __attribute__ ((aligned (8))) S8 { char a[8]; }; struct __attribute__ ((packed)) S { struct S8 s8; };
-Wpadded Warn if padding is included in a structure, either to align an element of the structure or to align the whole structure.  Sometimes when this happens it is possible to rearrange the fields of the structure to reduce the padding and so make the structure smaller.
-Wredundant-decls Warn if anything is declared more than once in the same scope, even in cases where multiple declaration is valid and changes nothing.
-Wrestrict Warn when an object referenced by a "restrict"-qualified parameter (or, in C++, a "__restrict"-qualified parameter) is aliased by another argument, or when copies between such objects overlap.  For example, the call to the "strcpy" function below attempts to truncate the string by replacing its initial characters with the last four. However, because the call writes the terminating NUL into "a[4]", the copies overlap and the call is diagnosed.
void foo (void) { char a[] = "abcd1234"; strcpy (a, a + 4); ... }
The -Wrestrict option detects some instances of simple overlap even without optimization but works best at -O2 and above.  It is included in -Wall.
-Wnested-externs (C and Objective-C only) Warn if an "extern" declaration is encountered within a function.
-Winline Warn if a function that is declared as inline cannot be inlined. Even with this option, the compiler does not warn about failures to inline functions declared in system headers.
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.
-Wint-in-bool-context Warn for suspicious use of integer values where boolean values are expected, such as conditional expressions (?:) using non-boolean integer constants in boolean context, like "if (a <= b ? 2 : 3)".  Or left shifting of signed integers in boolean context, like "for (a = 0; 1 << a; a++);".  Likewise for all kinds of multiplications regardless of the data type.  This warning is enabled by -Wall.
-Wno-int-to-pointer-cast Suppress warnings from casts to pointer type of an integer of a different size. In C++, casting to a pointer type of smaller size is an error. Wint-to-pointer-cast is enabled by default.
-Wno-pointer-to-int-cast (C and Objective-C only) Suppress warnings from casts from a pointer to an integer type of a different size.
-Winvalid-pch Warn if a precompiled header is found in the search path but cannot be used.
-Wlong-long Warn if "long long" type is used.  This is enabled by either -Wpedantic or -Wtraditional in ISO C90 and C++98 modes.  To inhibit the warning messages, use -Wno-long-long.
-Wvariadic-macros Warn if variadic macros are used in ISO C90 mode, or if the GNU alternate syntax is used in ISO C99 mode.  This is enabled by either -Wpedantic or -Wtraditional.  To inhibit the warning messages, use -Wno-variadic-macros.
-Wno-varargs Do not warn upon questionable usage of the macros used to handle variable arguments like "va_start".  These warnings are enabled by default.
-Wvector-operation-performance Warn if vector operation is not implemented via SIMD capabilities of the architecture.  Mainly useful for the performance tuning.  Vector operation can be implemented "piecewise", which means that the scalar operation is performed on every vector element; "in parallel", which means that the vector operation is implemented using scalars of wider type, which normally is more performance efficient; and "as a single scalar", which means that vector fits into a scalar type.
-Wvla Warn if a variable-length array is used in the code.  -Wno-vla prevents the -Wpedantic warning of the variable-length array.
-Wvla-larger-than=byte-size If this option is used, the compiler warns for declarations of variable-length arrays whose size is either unbounded, or bounded by an argument that allows the array size to exceed byte-size bytes. This is similar to how -Walloca-larger-than=byte-size works, but with variable-length arrays.
Note that GCC may optimize small variable-length arrays of a known value into plain arrays, so this warning may not get triggered for such arrays.
-Wvla-larger-than=PTRDIFF_MAX is enabled by default but is typically only effective when -ftree-vrp is active (default for -O2 and above).
See also -Walloca-larger-than=byte-size.
-Wno-vla-larger-than Disable -Wvla-larger-than= warnings.  The option is equivalent to -Wvla-larger-than=SIZE_MAX or larger.
-Wvla-parameter Warn about redeclarations of functions involving arguments of Variable Length Array types of inconsistent kinds or forms, and enable the detection of out-of-bounds accesses to such parameters by warnings such as -Warray-bounds.
If the first function declaration uses the VLA form the bound specified in the array is assumed to be the minimum number of elements expected to be provided in calls to the function and the maximum number of elements accessed by it.  Failing to provide arguments of sufficient size or accessing more than the maximum number of elements may be diagnosed.
For example, the warning triggers for the following redeclarations because the first one allows an array of any size to be passed to "f" while the second one specifies that the array argument must have at least "n" elements.  In addition, calling "f" with the assotiated VLA bound parameter in excess of the actual VLA bound triggers a warning as well.
void f (int n, int[n]); void f (int, int[]);     // warning: argument 2 previously declared as a VLA
void g (int n) { if (n > 4) return; int a[n]; f (sizeof a, a);     // warning: access to a by f may be out of bounds ... }
-Wvla-parameter is included in -Wall.  The -Warray-parameter option triggers warnings for similar problems involving ordinary array arguments.
-Wvolatile-register-var Warn if a register variable is declared volatile.  The volatile modifier does not inhibit all optimizations that may eliminate reads and/or writes to register variables.  This warning is enabled by -Wall.
-Wdisabled-optimization Warn if a requested optimization pass is disabled.  This warning does not generally indicate that there is anything wrong with your code; it merely indicates that GCC's optimizers are unable to handle the code effectively.  Often, the problem is that your code is too big or too complex; GCC refuses to optimize programs when the optimization itself is likely to take inordinate amounts of time.
-Wpointer-sign (C and Objective-C only) Warn for pointer argument passing or assignment with different signedness.  This option is only supported for C and Objective-C.  It is implied by -Wall and by -Wpedantic, which can be disabled with -Wno-pointer-sign.
-Wstack-protector This option is only active when -fstack-protector is active.  It warns about functions that are not protected against stack smashing.
-Woverlength-strings Warn about string constants that are longer than the "minimum maximum" length specified in the C standard.  Modern compilers generally allow string constants that are much longer than the standard's minimum limit, but very portable programs should avoid using longer strings.
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.
-Wunsuffixed-float-constants (C and Objective-C only) Issue a warning for any floating constant that does not have a suffix.  When used together with -Wsystem-headers it warns about such constants in system header files.  This can be useful when preparing code to use with the "FLOAT_CONST_DECIMAL64" pragma from the decimal floating-point extension to C99.
-Wno-lto-type-mismatch During the link-time optimization, do not warn about type mismatches in global declarations from different compilation units.  Requires -flto to be enabled.  Enabled by default.
-Wno-designated-init (C and Objective-C only) Suppress warnings when a positional initializer is used to initialize a structure that has been marked with the "designated_init" attribute.
Options That Control Static Analysis -fanalyzer This option enables an static analysis of program flow which looks for "interesting" interprocedural paths through the code, and issues warnings for problems found on them.
This analysis is much more expensive than other GCC warnings.
Enabling this option effectively enables the following warnings:
-Wanalyzer-double-fclose -Wanalyzer-double-free -Wanalyzer-exposure-through-output-file -Wanalyzer-file-leak -Wanalyzer-free-of-non-heap -Wanalyzer-malloc-leak -Wanalyzer-mismatching-deallocation -Wanalyzer-possible-null-argument -Wanalyzer-possible-null-dereference -Wanalyzer-null-argument -Wanalyzer-null-dereference -Wanalyzer-shift-count-negative -Wanalyzer-shift-count-overflow -Wanalyzer-stale-setjmp-buffer -Wanalyzer-tainted-array-index -Wanalyzer-unsafe-call-within-signal-handler -Wanalyzer-use-after-free -Wanalyzer-use-of-pointer-in-stale-stack-frame -Wanalyzer-write-to-const -Wanalyzer-write-to-string-literal
This option is only available if GCC was configured with analyzer support enabled.
-Wanalyzer-too-complex If -fanalyzer is enabled, the analyzer uses various heuristics to attempt to explore the control flow and data flow in the program, but these can be defeated by sufficiently complicated code.
By default, the analysis silently stops if the code is too complicated for the analyzer to fully explore and it reaches an internal limit.  The -Wanalyzer-too-complex option warns if this occurs.
-Wno-analyzer-double-fclose This warning requires -fanalyzer, which enables it; use -Wno-analyzer-double-fclose to disable it.
This diagnostic warns for paths through the code in which a "FILE *" can have "fclose" called on it more than once.
-Wno-analyzer-double-free This warning requires -fanalyzer, which enables it; use -Wno-analyzer-double-free to disable it.
This diagnostic warns for paths through the code in which a pointer can have a deallocator called on it more than once, either "free", or a deallocator referenced by attribute "malloc".
-Wno-analyzer-exposure-through-output-file This warning requires -fanalyzer, which enables it; use -Wno-analyzer-exposure-through-output-file to disable it.
This diagnostic warns for paths through the code in which a security- sensitive value is written to an output file (such as writing a password to a log file).
-Wno-analyzer-file-leak This warning requires -fanalyzer, which enables it; use -Wno-analyzer-file-leak to disable it.
This diagnostic warns for paths through the code in which a "<stdio.h>" "FILE *" stream object is leaked.
-Wno-analyzer-free-of-non-heap This warning requires -fanalyzer, which enables it; use -Wno-analyzer-free-of-non-heap to disable it.
This diagnostic warns for paths through the code in which "free" is called on a non-heap pointer (e.g. an on-stack buffer, or a global).
-Wno-analyzer-malloc-leak This warning requires -fanalyzer, which enables it; use -Wno-analyzer-malloc-leak to disable it.
This diagnostic warns for paths through the code in which a pointer allocated via an allocator is leaked: either "malloc", or a function marked with attribute "malloc".
-Wno-analyzer-mismatching-deallocation This warning requires -fanalyzer, which enables it; use -Wno-analyzer-mismatching-deallocation to disable it.
This diagnostic warns for paths through the code in which the wrong deallocation function is called on a pointer value, based on which function was used to allocate the pointer value.  The diagnostic will warn about mismatches between "free", scalar "delete" and vector "delete[]", and those marked as allocator/deallocator pairs using attribute "malloc".
-Wno-analyzer-possible-null-argument This warning requires -fanalyzer, which enables it; use -Wno-analyzer-possible-null-argument to disable it.
This diagnostic warns for paths through the code in which a possibly- NULL value is passed to a function argument marked with "__attribute__((nonnull))" as requiring a non-NULL value.
-Wno-analyzer-possible-null-dereference This warning requires -fanalyzer, which enables it; use -Wno-analyzer-possible-null-dereference to disable it.
This diagnostic warns for paths through the code in which a possibly- NULL value is dereferenced.
-Wno-analyzer-null-argument This warning requires -fanalyzer, which enables it; use -Wno-analyzer-null-argument to disable it.
This diagnostic warns for paths through the code in which a value known to be NULL is passed to a function argument marked with "__attribute__((nonnull))" as requiring a non-NULL value.
-Wno-analyzer-null-dereference This warning requires -fanalyzer, which enables it; use -Wno-analyzer-null-dereference to disable it.
This diagnostic warns for paths through the code in which a value known to be NULL is dereferenced.
-Wno-analyzer-shift-count-negative This warning requires -fanalyzer, which enables it; use -Wno-analyzer-shift-count-negative to disable it.
This diagnostic warns for paths through the code in which a shift is attempted with a negative count.  It is analogous to the -Wshift-count-negative diagnostic implemented in the C/C++ front ends, but is implemented based on analyzing interprocedural paths, rather than merely parsing the syntax tree.  However, the analyzer does not prioritize detection of such paths, so false negatives are more likely relative to other warnings.
-Wno-analyzer-shift-count-overflow This warning requires -fanalyzer, which enables it; use -Wno-analyzer-shift-count-overflow to disable it.
This diagnostic warns for paths through the code in which a shift is attempted with a count greater than or equal to the precision of the operand's type.  It is analogous to the -Wshift-count-overflow diagnostic implemented in the C/C++ front ends, but is implemented based on analyzing interprocedural paths, rather than merely parsing the syntax tree.  However, the analyzer does not prioritize detection of such paths, so false negatives are more likely relative to other warnings.
-Wno-analyzer-stale-setjmp-buffer This warning requires -fanalyzer, which enables it; use -Wno-analyzer-stale-setjmp-buffer to disable it.
This diagnostic warns for paths through the code in which "longjmp" is called to rewind to a "jmp_buf" relating to a "setjmp" call in a function that has returned.
When "setjmp" is called on a "jmp_buf" to record a rewind location, it records the stack frame.  The stack frame becomes invalid when the function containing the "setjmp" call returns.  Attempting to rewind to it via "longjmp" would reference a stack frame that no longer exists, and likely lead to a crash (or worse).
-Wno-analyzer-tainted-array-index This warning requires both -fanalyzer and -fanalyzer-checker=taint to enable it; use -Wno-analyzer-tainted-array-index to disable it.
This diagnostic warns for paths through the code in which a value that could be under an attacker's control is used as the index of an array access without being sanitized.
-Wno-analyzer-unsafe-call-within-signal-handler This warning requires -fanalyzer, which enables it; use -Wno-analyzer-unsafe-call-within-signal-handler to disable it.
This diagnostic warns for paths through the code in which a function known to be async-signal-unsafe (such as "fprintf") is called from a signal handler.
-Wno-analyzer-use-after-free This warning requires -fanalyzer, which enables it; use -Wno-analyzer-use-after-free to disable it.
This diagnostic warns for paths through the code in which a pointer is used after a deallocator is called on it: either "free", or a deallocator referenced by attribute "malloc".
-Wno-analyzer-use-of-pointer-in-stale-stack-frame This warning requires -fanalyzer, which enables it; use -Wno-analyzer-use-of-pointer-in-stale-stack-frame to disable it.
This diagnostic warns for paths through the code in which a pointer is dereferenced that points to a variable in a stale stack frame.
-Wno-analyzer-write-to-const This warning requires -fanalyzer, which enables it; use -Wno-analyzer-write-to-const to disable it.
This diagnostic warns for paths through the code in which the analyzer detects an attempt to write through a pointer to a "const" object.  However, the analyzer does not prioritize detection of such paths, so false negatives are more likely relative to other warnings.
-Wno-analyzer-write-to-string-literal This warning requires -fanalyzer, which enables it; use -Wno-analyzer-write-to-string-literal to disable it.
This diagnostic warns for paths through the code in which the analyzer detects an attempt to write through a pointer to a string literal.  However, the analyzer does not prioritize detection of such paths, so false negatives are more likely relative to other warnings.
Pertinent parameters for controlling the exploration are: --param analyzer-bb-explosion-factor=value, --param analyzer-max-enodes-per-program-point=value, --param analyzer-max-recursion-depth=value, and --param analyzer-min-snodes-for-call-summary=value.
The following options control the analyzer.
-fanalyzer-call-summaries Simplify interprocedural analysis by computing the effect of certain calls, rather than exploring all paths through the function from callsite to each possible return.
If enabled, call summaries are only used for functions with more than one call site, and that are sufficiently complicated (as per --param analyzer-min-snodes-for-call-summary=value).
-fanalyzer-checker=name Restrict the analyzer to run just the named checker, and enable it.
Some checkers are disabled by default (even with -fanalyzer), such as the "taint" checker that implements -Wanalyzer-tainted-array-index, and this option is required to enable them.
-fno-analyzer-feasibility This option is intended for analyzer developers.
By default the analyzer verifies that there is a feasible control flow path for each diagnostic it emits: that the conditions that hold are not mutually exclusive.  Diagnostics for which no feasible path can be found are rejected.  This filtering can be suppressed with -fno-analyzer-feasibility, for debugging issues in this code.
-fanalyzer-fine-grained This option is intended for analyzer developers.
Internally the analyzer builds an "exploded graph" that combines control flow graphs with data flow information.
By default, an edge in this graph can contain the effects of a run of multiple statements within a basic block.  With -fanalyzer-fine-grained, each statement gets its own edge.
-fanalyzer-show-duplicate-count This option is intended for analyzer developers: if multiple diagnostics have been detected as being duplicates of each other, it emits a note when reporting the best diagnostic, giving the number of additional diagnostics that were suppressed by the deduplication logic.
-fno-analyzer-state-merge This option is intended for analyzer developers.
By default the analyzer attempts to simplify analysis by merging sufficiently similar states at each program point as it builds its "exploded graph".  With -fno-analyzer-state-merge this merging can be suppressed, for debugging state-handling issues.
-fno-analyzer-state-purge This option is intended for analyzer developers.
By default the analyzer attempts to simplify analysis by purging aspects of state at a program point that appear to no longer be relevant e.g. the values of locals that aren't accessed later in the function and which aren't relevant to leak analysis.
With -fno-analyzer-state-purge this purging of state can be suppressed, for debugging state-handling issues.
-fanalyzer-transitivity This option enables transitivity of constraints within the analyzer.
-fanalyzer-verbose-edges This option is intended for analyzer developers.  It enables more verbose, lower-level detail in the descriptions of control flow within diagnostic paths.
-fanalyzer-verbose-state-changes This option is intended for analyzer developers.  It enables more verbose, lower-level detail in the descriptions of events relating to state machines within diagnostic paths.
-fanalyzer-verbosity=level This option controls the complexity of the control flow paths that are emitted for analyzer diagnostics.
The level can be one of:
0   At this level, interprocedural call and return events are displayed, along with the most pertinent state-change events relating to a diagnostic.  For example, for a double-"free" diagnostic, both calls to "free" will be shown.
1   As per the previous level, but also show events for the entry to each function.
2   As per the previous level, but also show events relating to control flow that are significant to triggering the issue (e.g. "true path taken" at a conditional).
This level is the default.
3   As per the previous level, but show all control flow events, not just significant ones.
4   This level is intended for analyzer developers; it adds various other events intended for debugging the analyzer.
-fdump-analyzer Dump internal details about what the analyzer is doing to file.analyzer.txt.  This option is overridden by -fdump-analyzer-stderr.
-fdump-analyzer-stderr Dump internal details about what the analyzer is doing to stderr. This option overrides -fdump-analyzer.
-fdump-analyzer-callgraph Dump a representation of the call graph suitable for viewing with GraphViz to file.callgraph.dot.
-fdump-analyzer-exploded-graph Dump a representation of the "exploded graph" suitable for viewing with GraphViz to file.eg.dot.  Nodes are color-coded based on state- machine states to emphasize state changes.
-fdump-analyzer-exploded-nodes Emit diagnostics showing where nodes in the "exploded graph" are in relation to the program source.
-fdump-analyzer-exploded-nodes-2 Dump a textual representation of the "exploded graph" to file.eg.txt.
-fdump-analyzer-exploded-nodes-3 Dump a textual representation of the "exploded graph" to one dump file per node, to file.eg-id.txt.  This is typically a large number of dump files.
-fdump-analyzer-feasibility Dump internal details about the analyzer's search for feasible paths. The details are written in a form suitable for viewing with GraphViz to filenames of the form file.*.fg.dot and file.*.tg.dot.
-fdump-analyzer-json Dump a compressed JSON representation of analyzer internals to file.analyzer.json.gz.  The precise format is subject to change.
-fdump-analyzer-state-purge As per -fdump-analyzer-supergraph, dump a representation of the "supergraph" suitable for viewing with GraphViz, but annotate the graph with information on what state will be purged at each node. The graph is written to file.state-purge.dot.
-fdump-analyzer-supergraph Dump representations of the "supergraph" suitable for viewing with GraphViz to file.supergraph.dot and to file.supergraph-eg.dot.  These show all of the control flow graphs in the program, with interprocedural edges for calls and returns.  The second dump contains annotations showing nodes in the "exploded graph" and diagnostics associated with them.
Options for Debugging Your Program To tell GCC to emit extra information for use by a debugger, in almost all cases you need only to add -g to your other options.
GCC allows you to use -g with -O.  The shortcuts taken by optimized code may occasionally be surprising: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values are already at hand; some statements may execute in different places because they have been moved out of loops.  Nevertheless it is possible to debug optimized output.  This makes it reasonable to use the optimizer for programs that might have bugs.
If you are not using some other optimization option, consider using -Og with -g.  With no -O option at all, some compiler passes that collect information useful for debugging do not run at all, so that -Og may result in a better debugging experience.
-g  Produce debugging information in the operating system's native format (stabs, COFF, XCOFF, or DWARF).  GDB can work with this debugging information.
On most systems that use stabs format, -g enables use of extra debugging information that only GDB can use; this extra information makes debugging work better in GDB but probably makes other debuggers crash or refuse to read the program.  If you want to control for certain whether to generate the extra information, use -gstabs+, -gstabs, -gxcoff+, -gxcoff, or -gvms (see below).
-ggdb Produce debugging information for use by GDB.  This means to use the most expressive format available (DWARF, stabs, or the native format if neither of those are supported), including GDB extensions if at all possible.
-gdwarf -gdwarf-version Produce debugging information in DWARF format (if that is supported). The value of version may be either 2, 3, 4 or 5; the default version for most targets is 5 (with the exception of VxWorks, TPF and Darwin/Mac OS X, which default to version 2, and AIX, which defaults to version 4).
Note that with DWARF Version 2, some ports require and always use some non-conflicting DWARF 3 extensions in the unwind tables.
Version 4 may require GDB 7.0 and -fvar-tracking-assignments for maximum benefit. Version 5 requires GDB 8.0 or higher.
GCC no longer supports DWARF Version 1, which is substantially different than Version 2 and later.  For historical reasons, some other DWARF-related options such as -fno-dwarf2-cfi-asm) retain a reference to DWARF Version 2 in their names, but apply to all currently-supported versions of DWARF.
-gstabs Produce debugging information in stabs format (if that is supported), without GDB extensions.  This is the format used by DBX on most BSD systems.  On MIPS, Alpha and System V Release 4 systems this option produces stabs debugging output that is not understood by DBX.  On System V Release 4 systems this option requires the GNU assembler.
-gstabs+ Produce debugging information in stabs format (if that is supported), using GNU extensions understood only by the GNU debugger (GDB).  The use of these extensions is likely to make other debuggers crash or refuse to read the program.
-gxcoff Produce debugging information in XCOFF format (if that is supported). This is the format used by the DBX debugger on IBM RS/6000 systems.
-gxcoff+ Produce debugging information in XCOFF format (if that is supported), using GNU extensions understood only by the GNU debugger (GDB).  The use of these extensions is likely to make other debuggers crash or refuse to read the program, and may cause assemblers other than the GNU assembler (GAS) to fail with an error.
-gvms Produce debugging information in Alpha/VMS debug format (if that is supported).  This is the format used by DEBUG on Alpha/VMS systems.
-glevel -ggdblevel -gstabslevel -gxcofflevel -gvmslevel Request debugging information and also use level to specify how much information.  The default level is 2.
Level 0 produces no debug information at all.  Thus, -g0 negates -g.
Level 1 produces minimal information, enough for making backtraces in parts of the program that you don't plan to debug.  This includes descriptions of functions and external variables, and line number tables, but no information about local variables.
Level 3 includes extra information, such as all the macro definitions present in the program.  Some debuggers support macro expansion when you use -g3.
If you use multiple -g options, with or without level numbers, the last such option is the one that is effective.
-gdwarf does not accept a concatenated debug level, to avoid confusion with -gdwarf-level.  Instead use an additional -glevel option to change the debug level for DWARF.
-fno-eliminate-unused-debug-symbols By default, no debug information is produced for symbols that are not actually used. Use this option if you want debug information for all symbols.
-femit-class-debug-always Instead of emitting debugging information for a C++ class in only one object file, emit it in all object files using the class.  This option should be used only with debuggers that are unable to handle the way GCC normally emits debugging information for classes because using this option increases the size of debugging information by as much as a factor of two.
-fno-merge-debug-strings Direct the linker to not merge together strings in the debugging information that are identical in different object files.  Merging is not supported by all assemblers or linkers.  Merging decreases the size of the debug information in the output file at the cost of increasing link processing time.  Merging is enabled by default.
-fdebug-prefix-map=old=new When compiling files residing in directory old, record debugging information describing them as if the files resided in directory new instead.  This can be used to replace a build-time path with an install-time path in the debug info.  It can also be used to change an absolute path to a relative path by using . for new.  This can give more reproducible builds, which are location independent, but may require an extra command to tell GDB where to find the source files. See also -ffile-prefix-map.
-fvar-tracking Run variable tracking pass.  It computes where variables are stored at each position in code.  Better debugging information is then generated (if the debugging information format supports this information).
It is enabled by default when compiling with optimization (-Os, -O, -O2, ...), debugging information (-g) and the debug info format supports it.
-fvar-tracking-assignments Annotate assignments to user variables early in the compilation and attempt to carry the annotations over throughout the compilation all the way to the end, in an attempt to improve debug information while optimizing.  Use of -gdwarf-4 is recommended along with it.
It can be enabled even if var-tracking is disabled, in which case annotations are created and maintained, but discarded at the end.  By default, this flag is enabled together with -fvar-tracking, except when selective scheduling is enabled.
-gsplit-dwarf If DWARF debugging information is enabled, separate as much debugging information as possible into a separate output file with the extension .dwo.  This option allows the build system to avoid linking files with debug information.  To be useful, this option requires a debugger capable of reading .dwo files.
-gdwarf32 -gdwarf64 If DWARF debugging information is enabled, the -gdwarf32 selects the 32-bit DWARF format and the -gdwarf64 selects the 64-bit DWARF format.  The default is target specific, on most targets it is -gdwarf32 though.  The 32-bit DWARF format is smaller, but can't support more than 2GiB of debug information in any of the DWARF debug information sections.  The 64-bit DWARF format allows larger debug information and might not be well supported by all consumers yet.
-gdescribe-dies Add description attributes to some DWARF DIEs that have no name attribute, such as artificial variables, external references and call site parameter DIEs.
-gpubnames Generate DWARF ".debug_pubnames" and ".debug_pubtypes" sections.
-ggnu-pubnames Generate ".debug_pubnames" and ".debug_pubtypes" sections in a format suitable for conversion into a GDB index.  This option is only useful with a linker that can produce GDB index version 7.
-fdebug-types-section When using DWARF Version 4 or higher, type DIEs can be put into their own ".debug_types" section instead of making them part of the ".debug_info" section.  It is more efficient to put them in a separate comdat section since the linker can then remove duplicates. But not all DWARF consumers support ".debug_types" sections yet and on some objects ".debug_types" produces larger instead of smaller debugging information.
-grecord-gcc-switches -gno-record-gcc-switches This switch causes the command-line options used to invoke the compiler that may affect code generation to be appended to the DW_AT_producer attribute in DWARF debugging information.  The options are concatenated with spaces separating them from each other and from the compiler version.  It is enabled by default.  See also -frecord-gcc-switches for another way of storing compiler options into the object file.
-gstrict-dwarf Disallow using extensions of later DWARF standard version than selected with -gdwarf-version.  On most targets using non-conflicting DWARF extensions from later standard versions is allowed.
-gno-strict-dwarf Allow using extensions of later DWARF standard version than selected with -gdwarf-version.
-gas-loc-support Inform the compiler that the assembler supports ".loc" directives. It may then use them for the assembler to generate DWARF2+ line number tables.
This is generally desirable, because assembler-generated line-number tables are a lot more compact than those the compiler can generate itself.
This option will be enabled by default if, at GCC configure time, the assembler was found to support such directives.
-gno-as-loc-support Force GCC to generate DWARF2+ line number tables internally, if DWARF2+ line number tables are to be generated.
-gas-locview-support Inform the compiler that the assembler supports "view" assignment and reset assertion checking in ".loc" directives.
This option will be enabled by default if, at GCC configure time, the assembler was found to support them.
-gno-as-locview-support Force GCC to assign view numbers internally, if -gvariable-location-views are explicitly requested.
-gcolumn-info -gno-column-info Emit location column information into DWARF debugging information, rather than just file and line.  This option is enabled by default.
-gstatement-frontiers -gno-statement-frontiers This option causes GCC to create markers in the internal representation at the beginning of statements, and to keep them roughly in place throughout compilation, using them to guide the output of "is_stmt" markers in the line number table.  This is enabled by default when compiling with optimization (-Os, -O, -O2, ...), and outputting DWARF 2 debug information at the normal level.
-gvariable-location-views -gvariable-location-views=incompat5 -gno-variable-location-views Augment variable location lists with progressive view numbers implied from the line number table.  This enables debug information consumers to inspect state at certain points of the program, even if no instructions associated with the corresponding source locations are present at that point.  If the assembler lacks support for view numbers in line number tables, this will cause the compiler to emit the line number table, which generally makes them somewhat less compact.  The augmented line number tables and location lists are fully backward-compatible, so they can be consumed by debug information consumers that are not aware of these augmentations, but they won't derive any benefit from them either.
This is enabled by default when outputting DWARF 2 debug information at the normal level, as long as there is assembler support, -fvar-tracking-assignments is enabled and -gstrict-dwarf is not. When assembler support is not available, this may still be enabled, but it will force GCC to output internal line number tables, and if -ginternal-reset-location-views is not enabled, that will most certainly lead to silently mismatching location views.
There is a proposed representation for view numbers that is not backward compatible with the location list format introduced in DWARF 5, that can be enabled with -gvariable-location-views=incompat5. This option may be removed in the future, is only provided as a reference implementation of the proposed representation.  Debug information consumers are not expected to support this extended format, and they would be rendered unable to decode location lists using it.
-ginternal-reset-location-views -gno-internal-reset-location-views Attempt to determine location views that can be omitted from location view lists.  This requires the compiler to have very accurate insn length estimates, which isn't always the case, and it may cause incorrect view lists to be generated silently when using an assembler that does not support location view lists.  The GNU assembler will flag any such error as a "view number mismatch".  This is only enabled on ports that define a reliable estimation function.
-ginline-points -gno-inline-points Generate extended debug information for inlined functions.  Location view tracking markers are inserted at inlined entry points, so that address and view numbers can be computed and output in debug information.  This can be enabled independently of location views, in which case the view numbers won't be output, but it can only be enabled along with statement frontiers, and it is only enabled by default if location views are enabled.
-gz[=type] Produce compressed debug sections in DWARF format, if that is supported.  If type is not given, the default type depends on the capabilities of the assembler and linker used.  type may be one of none (don't compress debug sections), zlib (use zlib compression in ELF gABI format), or zlib-gnu (use zlib compression in traditional GNU format).  If the linker doesn't support writing compressed debug sections, the option is rejected.  Otherwise, if the assembler does not support them, -gz is silently ignored when producing object files.
-femit-struct-debug-baseonly Emit debug information for struct-like types only when the base name of the compilation source file matches the base name of file in which the struct is defined.
This option substantially reduces the size of debugging information, but at significant potential loss in type information to the debugger.  See -femit-struct-debug-reduced for a less aggressive option.  See -femit-struct-debug-detailed for more detailed control.
This option works only with DWARF debug output.
-femit-struct-debug-reduced Emit debug information for struct-like types only when the base name of the compilation source file matches the base name of file in which the type is defined, unless the struct is a template or defined in a system header.
This option significantly reduces the size of debugging information, with some potential loss in type information to the debugger.  See -femit-struct-debug-baseonly for a more aggressive option.  See -femit-struct-debug-detailed for more detailed control.
-femit-struct-debug-detailed[=spec-list] Specify the struct-like types for which the compiler generates debug information.  The intent is to reduce duplicate struct debug information between different object files within the same program.
This option is a detailed version of -femit-struct-debug-reduced and -femit-struct-debug-baseonly, which serves for most needs.
A specification has the syntax[dir:|ind:][ord:|gen:](any|sys|base|none)
The optional first word limits the specification to structs that are used directly (dir:) or used indirectly (ind:).  A struct type is used directly when it is the type of a variable, member.  Indirect uses arise through pointers to structs.  That is, when use of an incomplete struct is valid, the use is indirect.  An example is struct one direct; struct two * indirect;.
The optional second word limits the specification to ordinary structs (ord:) or generic structs (gen:).  Generic structs are a bit complicated to explain.  For C++, these are non-explicit specializations of template classes, or non-template classes within the above.  Other programming languages have generics, but -femit-struct-debug-detailed does not yet implement them.
The third word specifies the source files for those structs for which the compiler should emit debug information.  The values none and any have the normal meaning.  The value base means that the base of name of the file in which the type declaration appears must match the base of the name of the main compilation file.  In practice, this means that when compiling foo.c, debug information is generated for types declared in that file and foo.h, but not other header files.  The value sys means those types satisfying base or declared in system or compiler headers.
You may need to experiment to determine the best settings for your application.
The default is -femit-struct-debug-detailed=all.
-fno-dwarf2-cfi-asm Emit DWARF unwind info as compiler generated ".eh_frame" section instead of using GAS ".cfi_*" directives.
-fno-eliminate-unused-debug-types Normally, when producing DWARF output, GCC avoids producing debug symbol output for types that are nowhere used in the source file being compiled.  Sometimes it is useful to have GCC emit debugging information for all types declared in a compilation unit, regardless of whether or not they are actually used in that compilation unit, for example if, in the debugger, you want to cast a value to a type that is not actually used in your program (but is declared).  More often, however, this results in a significant amount of wasted space.
Options That Control Optimization These options control various sorts of optimizations.