Options Controlling the Kind of Output#
Compilation can involve up to four stages: preprocessing, compilation proper, assembly and linking, always in that order. GCC is capable of preprocessing and compiling several files either into several assembler input files, or into one assembler input file; then each assembler input file produces an object file, and linking combines all the object files (those newly compiled, and those specified as input) into an executable file.
For any given input file, the file name suffix determines what kind of compilation is done:
C source code that must be preprocessed.
C source code that should not be preprocessed.
C++ source code that should not be preprocessed.
Objective-C source code. Note that you must link with the
libobjclibrary to make an Objective-C program work.
Objective-C source code that should not be preprocessed.
Objective-C++ source code. Note that you must link with the
libobjclibrary to make an Objective-C++ program work. Note that
.Mrefers to a literal capital M.
Objective-C++ source code that should not be preprocessed.
C, C++, Objective-C or Objective-C++ header file to be turned into a precompiled header (default), or C, C++ header file to be turned into an Ada spec (via the
C++ source code that must be preprocessed. Note that in
.cxx, the last two letters must both be literally
.Crefers to a literal capital C.
Objective-C++ source code that must be preprocessed.
Objective-C++ source code that should not be preprocessed.
C++ header file to be turned into a precompiled header or Ada spec.
Fixed form Fortran source code that should not be preprocessed.
Fixed form Fortran source code that must be preprocessed (with the traditional preprocessor).
Free form Fortran source code that should not be preprocessed.
Free form Fortran source code that must be preprocessed (with the traditional preprocessor).
Go source code.
D source code.
D interface file.
D documentation code (Ddoc).
Ada source code file that contains a library unit declaration (a declaration of a package, subprogram, or generic, or a generic instantiation), or a library unit renaming declaration (a package, generic, or subprogram renaming declaration). Such files are also called specs.
Ada source code file containing a library unit body (a subprogram or package body). Such files are also called bodies.
Assembler code that must be preprocessed.
An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way.
You can specify the input language explicitly with the
Specify explicitly the
languagefor the following input files (rather than letting the compiler choose a default based on the file name suffix). This option applies to all following input files until the next
-xoption. Possible values for
Turn off any specification of a language, so that subsequent files are handled according to their file name suffixes (as they are if
-xhas not been used at all).
If you only want some of the stages of compilation, you can use
-x (or filename suffixes) to tell gcc where to start, and
one of the options
-E to say where
gcc is to stop. Note that some combinations (for example,
-x cpp-output -E) instruct gcc to do nothing at all.
Compile or assemble the source files, but do not link. The linking stage simply is not done. The ultimate output is in the form of an object file for each source file.
By default, the object file name for a source file is made by replacing the suffix
.s, etc., with
Unrecognized input files, not requiring compilation or assembly, are ignored.
Stop after the stage of compilation proper; do not assemble. The output is in the form of an assembler code file for each non-assembler input file specified.
By default, the assembler file name for a source file is made by replacing the suffix
.i, etc., with
Input files that don’t require compilation are ignored.
Stop after the preprocessing stage; do not run the compiler proper. The output is in the form of preprocessed source code, which is sent to the standard output.
Input files that don’t require preprocessing are ignored.
- -o file#
Place the primary output in file
file. This applies to whatever sort of output is being produced, whether it be an executable file, an object file, an assembler file or preprocessed C code.
-ois not specified, the default is to put an executable file in
a.out, the object file for
source.o, its assembler file in
source.s, a precompiled header file in
source.suffix.gch, and all preprocessed C source on standard output.
-onames only the primary output, it also affects the naming of auxiliary and dump outputs. See the examples below. Unless overridden, both auxiliary outputs and dump outputs are placed in the same directory as the primary output. In auxiliary outputs, the suffix of the input file is replaced with that of the auxiliary output file type; in dump outputs, the suffix of the dump file is appended to the input file suffix. In compilation commands, the base name of both auxiliary and dump outputs is that of the primary output; in compile and link commands, the primary output name, minus the executable suffix, is combined with the input file name. If both share the same base name, disregarding the suffix, the result of the combination is that base name, otherwise, they are concatenated, separated by a dash.
gcc -c foo.c ...
foo.oas the primary output, and place aux outputs and dumps next to it, e.g., aux file
-gsplit-dwarf, and dump file
If a non-linker output file is explicitly specified, aux and dump files by default take the same base name:
gcc -c foo.c -o dir/foobar.o ...
will name aux outputs
dir/foobar.*and dump outputs
A linker output will instead prefix aux and dump outputs:
gcc foo.c bar.c -o dir/foobar ...
will generally name aux outputs
dir/foobar-bar.*, and dump outputs
The one exception to the above is when the executable shares the base name with the single input:
gcc foo.c -o dir/foo ...
in which case aux outputs are named
dir/foo.*and dump outputs named
The location and the names of auxiliary and dump outputs can be adjusted by the options
- -dumpbase dumpbase#
This option sets the base name for auxiliary and dump output files. It does not affect the name of the primary output file. Intermediate outputs, when preserved, are not regarded as primary outputs, but as auxiliary outputs:
gcc -save-temps -S foo.c
saves the (no longer) temporary preprocessed file in
foo.i, and then compiles to the (implied) output file
gcc -save-temps -dumpbase save-foo -c foo.c
preprocesses to in
save-foo.i, compiles to
save-foo.s(now an intermediate, thus auxiliary output), and then assembles to the (implied) output file
Absent this option, dump and aux files take their names from the input file, or from the (non-linker) output file, if one is explicitly specified: dump output files (e.g. those requested by
-fdump-*options) with the input name suffix, and aux output files (those requested by other non-dump options, e.g.
-fcallgraph-info) without it.
Similar suffix differentiation of dump and aux outputs can be attained for explicitly-given
-dumpbase basename.sufby also specifying
dumpbaseis explicitly specified with any directory component, any
-save-temps=*) is ignored, and instead of appending to it,
dumpbasefully overrides it:
gcc foo.c -c -o dir/foo.o -dumpbase alt/foo \ -dumpdir pfx- -save-temps=cwd ...
creates auxiliary and dump outputs named
./prefix implied by
-dumpbaseis specified in a command that compiles multiple inputs, or that compiles and then links, it may be combined with
dumppfx, as specified under
-dumpdir. Then, each input file is compiled using the combined
dumppfx, and default values for
auxdropsufare computed for each input file:
gcc foo.c bar.c -c -dumpbase main ...
bar.oas primary outputs, and avoids overwriting the auxiliary and dump outputs by using the
dumpbaseas a prefix, creating auxiliary and dump outputs named
An empty string specified as
dumpbaseavoids the influence of the output basename in the naming of auxiliary and dump outputs during compilation, computing default values :
gcc -c foo.c -o dir/foobar.o -dumpbase '' ...
will name aux outputs
dir/foo.*and dump outputs
dir/foo.c.*. Note how their basenames are taken from the input name, but the directory still defaults to that of the output.
The empty-string dumpbase does not prevent the use of the output basename for outputs during linking:
gcc foo.c bar.c -o dir/foobar -dumpbase '' -flto ...
The compilation of the source files will name auxiliary outputs
dir/bar.*, and dump outputs
dir/bar.c.*. LTO recompilation during linking will use
dir/foobar.as the prefix for dumps and auxiliary files.
- -dumpbase-ext auxdropsuf#
When forming the name of an auxiliary (but not a dump) output file, drop trailing
dumpbasebefore appending any suffixes. If not specified, this option defaults to the suffix of a default
dumpbase, i.e., the suffix of the input file when
-dumpbaseis not present in the command line, or
dumpbaseis combined with
gcc foo.c -c -o dir/foo.o -dumpbase x-foo.c -dumpbase-ext .c ...
dir/foo.oas the main output, and generates auxiliary outputs in
dir/x-foo.*, taking the location of the primary output, and dropping the
.csuffix from the
dumpbase. Dump outputs retain the suffix:
This option is disregarded if it does not match the suffix of a specified
dumpbase, except as an alternative to the executable suffix when appending the linker output base name to
dumppfx, as specified below:
gcc foo.c bar.c -o main.out -dumpbase-ext .out ...
main.outas the primary output, and avoids overwriting the auxiliary and dump outputs by using the executable name minus
auxdropsufas a prefix, creating auxiliary outputs named
main-bar.*and dump outputs named
- -dumpdir dumppfx#
When forming the name of an auxiliary or dump output file, use
dumppfxas a prefix:
gcc -dumpdir pfx- -c foo.c ...
foo.oas the primary output, and auxiliary outputs named
pfx-foo.*, combining the given
dumppfxwith the default
dumpbasederived from the default primary output, derived in turn from the input name. Dump outputs also take the input name suffix:
dumppfxis to be used as a directory name, it must end with a directory separator:
gcc -dumpdir dir/ -c foo.c -o obj/bar.o ...
obj/bar.oas the primary output, and auxiliary outputs named
dir/bar.*, combining the given
dumppfxwith the default
dumpbasederived from the primary output name. Dump outputs also take the input name suffix:
It defaults to the location of the output file, unless the output file is a special file like
-save-temps=objoverride this default, just like an explicit
-dumpdiroption. In case multiple such options are given, the last one prevails:
gcc -dumpdir pfx- -c foo.c -save-temps=obj ...
foo.o, with auxiliary outputs named
dumppfxgiven by the earlier
-dumpdiroption. It does not matter that =obj is the default for
-save-temps, nor that the output directory is implicitly the current directory. Dump outputs are named
When compiling from multiple input files, if
dumpbase, minus a
auxdropsufsuffix, and a dash are appended to (or override, if containing any directory components) an explicit or defaulted
dumppfx, so that each of the multiple compilations gets differently-named aux and dump outputs.
gcc foo.c bar.c -c -dumpdir dir/pfx- -dumpbase main ...
outputs auxiliary dumps to
dumppfx. Dump outputs retain the input file suffix:
dir/pfx-main-bar.c.*, respectively. Contrast with the single-input compilation:
gcc foo.c -c -dumpdir dir/pfx- -dumpbase main ...
-dumpbaseto a single source, does not compute and append a separate
dumpbaseper input file. Its auxiliary and dump outputs go in
When compiling and then linking from multiple input files, a defaulted or explicitly specified
dumppfxalso undergoes the
dumpbase- transformation above (e.g. the compilation of
bar.cabove, but without
-c). If neither
-dumpbaseare given, the linker output base name, minus
auxdropsuf, if specified, or the executable suffix otherwise, plus a dash is appended to the default
dumppfxinstead. Note, however, that unlike earlier cases of linking:
gcc foo.c bar.c -dumpdir dir/pfx- -o main ...
does not append the output name
-dumpdiris explicitly specified. The goal is that the explicitly-specified
dumppfxmay contain the specified output name as part of the prefix, if desired; only an explicitly-specified
-dumpbasewould be combined with it, in order to avoid simply discarding a meaningful option.
When compiling and then linking from a single input file, the linker output base name will only be appended to the default
dumppfxas above if it does not share the base name with the single input file name. This has been covered in single-input linking cases above, but not with an explicit
-dumpdirthat inhibits the combination, even if overridden by
gcc foo.c -dumpdir alt/pfx- -o dir/main.exe -save-temps=cwd ...
Auxiliary outputs are named
foo.*, and dump outputs
foo.c.*, in the current working directory as ultimately requested by
Summing it all up for an intuitive though slightly imprecise data flow: the primary output name is broken into a directory part and a basename part;
dumppfxis set to the former, unless overridden by
dumpbaseis set to the latter, unless overriden by
-dumpbase. If there are multiple inputs or linking, this
dumpbasemay be combined with
dumppfxand taken from each input file. Auxiliary output names for each input are formed by combining
dumpbaseminus suffix, and the auxiliary output suffix; dump output names are only different in that the suffix from
When it comes to auxiliary and dump outputs created during LTO recompilation, a combination of
dumpbase, as given or as derived from the linker output name but not from inputs, even in cases in which this combination would not otherwise be used as such, is passed down with a trailing period replacing the compiler-added dash, if any, as a
-dumpdiroption to lto-wrapper; being involved in linking, this program does not normally get any
-dumpbase-ext, and it ignores them.
When running sub-compilers, lto-wrapper appends LTO stage names to the received
dumppfx, ensures it contains a directory component so that it overrides any
-dumpdir, and passes that as
Print (on standard error output) the commands executed to run the stages of compilation. Also print the version number of the compiler driver program and of the preprocessor and the compiler proper.
-vexcept the commands are not executed and arguments are quoted unless they contain only alphanumeric characters or
./-_. This is useful for shell scripts to capture the driver-generated command lines.
Print (on the standard output) a description of the command-line options understood by gcc. If the
-voption is also specified then
--helpis also passed on to the various processes invoked by gcc, so that they can display the command-line options they accept. If the
-Wextraoption has also been specified (prior to the
--helpoption), then command-line options that have no documentation associated with them are also displayed.
Print (on the standard output) a description of target-specific command-line options for each tool. For some targets extra target-specific information may also be printed.
Print (on the standard output) a description of the command-line options understood by the compiler that fit into all specified classes and qualifiers. These are the supported classes:
Display all of the optimization options supported by the compiler.
Display all of the options controlling warning messages produced by the compiler.
Display target-specific options. Unlike the
--target-helpoption however, target-specific options of the linker and assembler are not displayed. This is because those tools do not currently support the extended
Display the values recognized by the
Display the options supported for
languageis the name of one of the languages supported in this version of GCC. If an option is supported by all languages, one needs to select
Display the options that are common to all languages.
These are the supported qualifiers:
Display only those options that are undocumented.
Display options taking an argument that appears after an equal sign in the same continuous piece of text, such as:
Display options taking an argument that appears as a separate word following the original option, such as:
Thus for example to display all the undocumented target-specific switches supported by the compiler, use:
--help=target,undocumentedThe sense of a qualifier can be inverted by prefixing it with the
^character, so for example to display all binary warning options (i.e., ones that are either on or off and that do not take an argument) that have a description, use:
--help=warnings,^joined,^undocumentedThe argument to
--help=should not consist solely of inverted qualifiers.
Combining several classes is possible, although this usually restricts the output so much that there is nothing to display. One case where it does work, however, is when one of the classes is
target. For example, to display all the target-specific optimization options, use:
--help=option can be repeated on the command line. Each successive use displays its requested class of options, skipping those that have already been displayed. If
--helpis also specified anywhere on the command line then this takes precedence over any
-Qoption appears on the command line before the
--help=option, then the descriptive text displayed by
--help=is changed. Instead of describing the displayed options, an indication is given as to whether the option is enabled, disabled or set to a specific value (assuming that the compiler knows this at the point where the
--help=option is used).
Here is a truncated example from the ARM port of gcc:
% gcc -Q -mabi=2 --help=target -c The following options are target specific: -mabi= 2 -mabort-on-noreturn [disabled] -mapcs [disabled]
The output is sensitive to the effects of previous command-line options, so for example it is possible to find out which optimizations are enabled at
--help=optimizersAlternatively you can discover which binary optimizations are enabled by
gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts diff /tmp/O2-opts /tmp/O3-opts | grep enabled
Display the version number and copyrights of the invoked GCC.
Normally the gcc program exits with the code of 1 if any phase of the compiler returns a non-success return code. If you specify
-pass-exit-codes, the gcc program instead returns with the numerically highest error produced by any phase returning an error indication. The C, C++, and Fortran front ends return 4 if an internal compiler error is encountered.
Use pipes rather than temporary files for communication between the various stages of compilation. This fails to work on some systems where the assembler is unable to read from a pipe; but the GNU assembler has no trouble.
fileafter the compiler reads in the standard
specsfile, in order to override the defaults which the gcc driver program uses when determining what switches to pass to cc1, cc1plus, as, ld, etc. More than one
-specs=filecan be specified on the command line, and they are processed in order, from left to right. See Specifying Subprocesses and the Switches to Pass to Them, for information about the format of the
Invoke all subcommands under a wrapper program. The name of the wrapper program and its parameters are passed as a comma separated list.
gcc -c t.c -wrapper gdb,--args
This invokes all subprograms of gcc under
gdb --args, thus the invocation of cc1 is
gdb --args cc1 ....
When compiling files residing in directory
old, record any references to them in the result of the compilation as if the files resided in directory
newinstead. Specifying this option is equivalent to specifying all the individual
-f*-prefix-mapoptions. This can be used to make reproducible builds that are location independent. See also
Load the plugin code in file
name.so, assumed to be a shared object to be dlopen’d by the compiler. The base name of the shared object file is used to identify the plugin for the purposes of argument parsing (See
-fplugin-arg-name-key=valuebelow). Each plugin should define the callback functions specified in the Plugins API.
Define an argument called
keywith a value of
valuefor the plugin called
For C and C++ source and include files, generate corresponding Ada specs. See Generating Ada Bindings for C and C++ headers, which provides detailed documentation on this feature.
In conjunction with
-fdump-ada-spec[-slim]above, generate Ada specs as child units of parent
For input files in any language, generate corresponding Go declarations in
file. This generates Go
funcdeclarations which may be a useful way to start writing a Go interface to code written in some other language.
Read command-line options from
file. The options read are inserted in place of the original
filedoes not exist, or cannot be read, then the option will be treated literally, and not removed.
fileare separated by whitespace. A whitespace character may be included in an option by surrounding the entire option in either single or double quotes. Any character (including a backslash) may be included by prefixing the character to be included with a backslash. The
filemay itself contain additional
@fileoptions; any such options will be processed recursively.