| www.delorie.com/gnu/docs/gcc/gcc.1.html | search |
 Buy the book! | |
| www.delorie.com/gnu/docs/gcc/gcc.1.html | search |
|
Buy the book! | |
Only the most useful options are listed here; see below for the remainder. g++ accepts mostly the same options as gcc.
Other options are passed on to one stage of processing. Some options control the preprocessor and others the compiler itself. Yet other options control the assembler and linker; most of these are not documented here, since you rarely need to use any of them.
Most of the command line options that you can use with GCC are useful for C programs; when an option is only useful with another language (usually [C+]), the explanation says so explicitly. If the description for a particular option does not mention a source language, you can use that option with all supported languages.
The gcc program accepts options and file names as operands. Many options have multi-letter names; therefore multiple single-letter options may not be grouped: -dr is very different from -d -r.
You can mix options and other arguments. For the most part, the order you use doesn't matter. Order does matter when you use several options of the same kind; for example, if you specify -L more than once, the directories are searched in the order specified.
Many options have long names starting with -f or with -W---for example, -fforce-mem, -fstrength-reduce, -Wformat and so on. Most of these have both positive and negative forms; the negative form of -ffoo would be -fno-foo. This manual documents only one of these two forms, whichever one is not the default.
For any given input file, the file name suffix determines what kind of compilation is done: C source code which must be preprocessed. C source code which should not be preprocessed. [C+] source code which should not be preprocessed. Objective-C source code. Note that you must link with the library libobjc.a to make an Objective-C program work. Objective-C source code which should not be preprocessed. C header file (not to be compiled or linked). [C+] source code which must be preprocessed. Note that in .cxx, the last two letters must both be literally x. Likewise, .C refers to a literal capital C. Fortran source code which should not be preprocessed. Fortran source code which must be preprocessed (with the traditional preprocessor). Fortran source code which must be preprocessed with a RATFOR preprocessor (not included with GCC). Ada source code file which 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. Assembler code which 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 -x option:
Specify explicitly the language for 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 -x option. Possible values for language are:
c c-header cpp-output
c++ c++-cpp-output
objective-c objc-cpp-output
assembler assembler-with-cpp
ada
f77 f77-cpp-input ratfor
java
Turn off any specification of a language, so that subsequent files are
handled according to their file name suffixes (as they are if -x
has not been used at all).
Normally the gcc program will exit 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 will instead return with
numerically highest error produced by any phase that returned an error
indication.
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 -c, -S, or -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 .c, .i, .s, etc., with .o.
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 .c, .i, etc., with .s.
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 which don't require preprocessing are ignored.
Place output in file file. This applies regardless to whatever
sort of output is being produced, whether it be an executable file,
an object file, an assembler file or preprocessed C code.
Since only one output file can be specified, it does not make sense to
use -o when compiling more than one input file, unless you are
producing an executable file as output.
If -o is not specified, the default is to put an executable file
in a.out, the object file for source.suffix in
source.o, its assembler file in source.s, and
all preprocessed C source on standard output.
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.
Like -v except the commands are not executed and all command
arguments are quoted. This is useful for shell scripts to capture the
driver-generated command lines.
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.
Print (on the standard output) a description of the command line options
understood by gcc. If the -v option is also specified
then [--]help will also be passed on to the various processes
invoked by gcc, so that they can display the command line options
they accept. If the -W option is also specified then command
line options which have no documentation associated with them will also
be displayed.
Print (on the standard output) a description of target specific command
line options for each tool.
Display the version number and copyrights of the invoked GCC.
[C+] source files conventionally use one of the suffixes .C,
.cc, .cpp, .c++, .cp, or .cxx;
preprocessed [C+] files use the suffix .ii. GCC recognizes
files with these names and compiles them as [C+] programs even if you
call the compiler the same way as for compiling C programs (usually with
the name gcc).
However, [C+] programs often require class libraries as well as a compiler that understands the [C+] language---and under some circumstances, you might want to compile programs from standard input, or otherwise without a suffix that flags them as [C+] programs. g++ is a program that calls GCC with the default language set to [C+], and automatically specifies linking against the [C+] library. On many systems, g++ is also installed with the name c++.
When you compile [C+] programs, you may specify many of the same
command-line options that you use for compiling programs in any
language; or command-line options meaningful for C and related
languages; or options that are meaningful only for [C+] programs.
The following options control the dialect of C (or languages derived
from C, such as [C+] and Objective-C) that the compiler accepts:
In C mode, support all ISO C89 programs. In [C+] mode,
remove GNU extensions that conflict with ISO [C+].
This turns off certain features of GCC that are incompatible with ISO
C89 (when compiling C code), or of standard [C+] (when compiling [C+] code),
such as the [C`]asm[C'] and [C`]typeof[C'] keywords, and
predefined macros such as [C`]unix[C'] and [C`]vax[C'] that identify the
type of system you are using. It also enables the undesirable and
rarely used ISO trigraph feature. For the C compiler,
it disables recognition of [C+] style // comments as well as
the [C`]inline[C'] keyword.
The alternate keywords [C`]__asm__[C'], [C`]__extension__[C'],
[C`]__inline__[C'] and [C`]__typeof__[C'] continue to work despite
-ansi. You would not want to use them in an ISO C program, of
course, but it is useful to put them in header files that might be included
in compilations done with -ansi. Alternate predefined macros
such as [C`]__unix__[C'] and [C`]__vax__[C'] are also available, with or
without -ansi.
The -ansi option does not cause non-ISO programs to be
rejected gratuitously. For that, -pedantic is required in
addition to -ansi.
The macro [C`]__STRICT_ANSI__[C'] is predefined when the -ansi
option is used. Some header files may notice this macro and refrain
from declaring certain functions or defining certain macros that the
ISO standard doesn't call for; this is to avoid interfering with any
programs that might use these names for other things.
Functions which would normally be built in but do not have semantics
defined by ISO C (such as [C`]alloca[C'] and [C`]ffs[C']) are not built-in
functions with -ansi is used.
Determine the language standard. This option is currently only
supported when compiling C. A value for this option must be provided;
possible values are
g++ -g -frepo -O -c firstClass.C In this example, only -frepo is an option meant only for [C+] programs; you can use the other options with any language supported by GCC.
Here is a list of options that are only for compiling [C+] programs:
Turn off all access checking. This switch is mainly useful for working
around bugs in the access control code.
Check that the pointer returned by [C`]operator new[C'] is non-null
before attempting to modify the storage allocated. The current Working
Paper requires that [C`]operator new[C'] never return a null pointer, so
this check is normally unnecessary.
An alternative to using this option is to specify that your
[C`]operator new[C'] does not throw any exceptions; if you declare it
BIthrow(), G++ will check the return value. See also new
(nothrow).
Put uninitialized or runtime-initialized global variables into the
common segment, as C does. This saves space in the executable at the
cost of not diagnosing duplicate definitions. If you compile with this
flag and your program mysteriously crashes after [C`]main()[C'] has
completed, you may have an object that is being destroyed twice because
two definitions were merged.
This option is no longer useful on most targets, now that support has
been added for putting variables into BSS without making them common.
Give string constants type [C`]char *[C'] instead of type [C`]const
char *[C']. By default, G++ uses type [C`]const char *[C'] as required by
the standard. Even if you use -fno-const-strings, you cannot
actually modify the value of a string constant, unless you also use
-fwritable-strings.
This option might be removed in a future release of G++. For maximum
portability, you should structure your code so that it works with
string constants that have type [C`]const char *[C'].
Accept $ in identifiers. You can also explicitly prohibit use of
$ with the option -fno-dollars-in-identifiers. (GNU C allows
$ by default on most target systems, but there are a few exceptions.)
Traditional C allowed the character $ to form part of
identifiers. However, ISO C and [C+] forbid $ in identifiers.
The [C+] standard allows an implementation to omit creating a temporary
which is only used to initialize another object of the same type.
Specifying this option disables that optimization, and forces G++ to
call the copy constructor in all cases.
Don't check for violation of exception specifications at runtime. This
option violates the [C+] standard, but may be useful for reducing code
size in production builds, much like defining NDEBUG. The compiler
will still optimize based on the exception specifications.
Cause #pragma interface and implementation to apply to
template instantiation; template instances are emitted or not according
to the location of the template definition.
This option is deprecated.
Similar to -fexternal-templates, but template instances are
emitted or not according to the place where they are first instantiated.
This option is deprecated.
If -ffor-scope is specified, the scope of variables declared in
a for-init-statement is limited to the for loop itself,
as specified by the [C+] standard.
If -fno-for-scope is specified, the scope of variables declared in
a for-init-statement extends to the end of the enclosing scope,
as was the case in old versions of G++, and other (traditional)
implementations of [C+].
The default if neither flag is given to follow the standard,
but to allow and give a warning for old-style code that would
otherwise be invalid, or have different behavior.
Do not recognize [C`]typeof[C'] as a keyword, so that code can use this
word as an identifier. You can use the keyword [C`]__typeof__[C'] instead.
-ansi implies -fno-gnu-keywords.
Never emit code for non-inline templates which are instantiated
implicitly (i.e. by use); only emit code for explicit instantiations.
Don't emit code for implicit instantiations of inline templates, either.
The default is to handle inlines differently so that compiles with and
without optimization will need the same set of explicit instantiations.
To save space, do not emit out-of-line copies of inline functions
controlled by #pragma implementation. This will cause linker
errors if these functions are not inlined everywhere they are called.
Disable pedantic warnings about constructs used in MFC, such as implicit
int and getting a pointer to member function via non-standard syntax.
Disable built-in declarations of functions that are not mandated by
ANSI/ISO C. These include [C`]ffs[C'], [C`]alloca[C'], [C`]_exit[C'],
[C`]index[C'], [C`]bzero[C'], [C`]conjf[C'], and other related functions.
Do not treat the operator name keywords [C`]and[C'], [C`]bitand[C'],
[C`]bitor[C'], [C`]compl[C'], [C`]not[C'], [C`]or[C'] and [C`]xor[C'] as
synonyms as keywords.
Disable diagnostics that the standard says a compiler does not need to
issue. Currently, the only such diagnostic issued by G++ is the one for
a name having multiple meanings within a class.
Downgrade messages about nonconformant code from errors to warnings. By
default, G++ effectively sets -pedantic-errors without
-pedantic; this option reverses that. This behavior and this
option are superseded by -pedantic, which works as it does for GNU C.
Enable automatic template instantiation at link time. This option also
implies -fno-implicit-templates.
Disable generation of information about every class with virtual
functions for use by the [C+] runtime type identification features
(dynamic_cast and typeid). If you don't use those parts
of the language, you can save some space by using this flag. Note that
exception handling uses the same information, but it will generate it as
needed.
Emit statistics about front-end processing at the end of the compilation.
This information is generally only useful to the G++ development team.
Set the maximum instantiation depth for template classes to n.
A limit on the template instantiation depth is needed to detect
endless recursions during template class instantiation. ANSI/ISO [C+]
conforming programs must not rely on a maximum depth greater than 17.
Register destructors for objects with static storage duration with the
[C`]__cxa_atexit[C'] function rather than the [C`]atexit[C'] function.
This option is required for fully standards-compliant handling of static
destructors, but will only work if your C library supports
[C`]__cxa_atexit[C'].
Emit special relocations for vtables and virtual function references
so that the linker can identify unused virtual functions and zero out
vtable slots that refer to them. This is most useful with
-ffunction-sections and -Wl,--gc-sections, in order to
also discard the functions themselves.
This optimization requires GNU as and GNU ld. Not all systems support
this option. -Wl,--gc-sections is ignored without -static.
Do not use weak symbol support, even if it is provided by the linker.
By default, G++ will use weak symbols if they are available. This
option exists only for testing, and should not be used by end-users;
it will result in inferior code and has no benefits. This option may
be removed in a future release of G++.
Do not search for header files in the standard directories specific to
[C+], but do still search the other standard directories. (This option
is used when building the [C+] library.)
In addition, these optimization, warning, and code generation options
have meanings only for [C+] programs:
Do not assume inline for functions defined inside a class scope.
Note that these
functions will have linkage like inline functions; they just won't be
inlined by default.
Warn when G++ generates code that is probably not compatible with the
vendor-neutral [C+] ABI. Although an effort has been made to warn about
all such cases, there are probably some cases that are not warned about,
even though G++ is generating incompatible code. There may also be
cases where warnings are emitted even though the code that is generated
will be compatible.
You should rewrite your code to avoid these warnings if you are
concerned about the fact that code generated by G++ may not be binary
compatible with code generated by other compilers.
The known incompatibilites at this point include:
The following -W... options are not affected by -Wall. Warn about violations of the following style guidelines from Scott Meyers' Effective [C+] book:
gcc -g -fgnu-runtime -O -c some_class.m In this example, only -fgnu-runtime is an option meant only for Objective-C programs; you can use the other options with any language supported by GCC.
Here is a list of options that are only for compiling Objective-C programs: Use class-name as the name of the class to instantiate for each literal string specified with the syntax [C`]@"..."[C']. The default class name is [C`]NXConstantString[C']. Generate object code compatible with the standard GNU Objective-C runtime. This is the default for most types of systems. Generate output compatible with the NeXT runtime. This is the default for NeXT-based systems, including Darwin and Mac OS X. Dump interface declarations for all classes seen in the source file to a file named sourcename.decl. Do not warn if methods required by a protocol are not implemented in the class adopting it. Warn if a selector has multiple methods of different types defined. Traditionally, diagnostic messages have been formatted irrespective of the output device's aspect (e.g. its width, ...). The options described below can be used to control the diagnostic messages formatting algorithm, e.g. how many characters per line, how often source location information should be reported. Right now, only the [C+] front end can honor these options. However it is expected, in the near future, that the remaining front ends would be able to digest them correctly. Try to format error messages so that they fit on lines of about n characters. The default is 72 characters for g++ and 0 for the rest of the front ends supported by GCC. If n is zero, then no line-wrapping will be done; each error message will appear on a single line. Only meaningful in line-wrapping mode. Instructs the diagnostic messages reporter to emit once source location information; that is, in case the message is too long to fit on a single physical line and has to be wrapped, the source location won't be emitted (as prefix) again, over and over, in subsequent continuation lines. This is the default behavior. Only meaningful in line-wrapping mode. Instructs the diagnostic messages reporter to emit the same source location information (as prefix) for physical lines that result from the process of breaking a message which is too long to fit on a single line. Warnings are diagnostic messages that report constructions which are not inherently erroneous but which are risky or suggest there may have been an error.
You can request many specific warnings with options beginning -W, for example -Wimplicit to request warnings on implicit declarations. Each of these specific warning options also has a negative form beginning -Wno- to turn off warnings; for example, -Wno-implicit. This manual lists only one of the two forms, whichever is not the default.
The following options control the amount and kinds of warnings produced
by GCC; for further, language-specific options also refer to
@ref{[C+] Dialect Options} and @ref{Objective-C Dialect Options}.
Check the code for syntax errors, but don't do anything beyond that.
Issue all the warnings demanded by strict ISO C and ISO [C+];
reject all programs that use forbidden extensions, and some other
programs that do not follow ISO C and ISO [C+]. For ISO C, follows the
version of the ISO C standard specified by any -std option used.
Valid ISO C and ISO [C+] programs should compile properly with or without
this option (though a rare few will 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.
-pedantic does not cause warning messages for use of the
alternate keywords whose names begin and end with __. Pedantic
warnings are also disabled in the expression that follows
[C`]__extension__[C']. However, only system header files should use
these escape routes; application programs should avoid them.
Some users try to use -pedantic to check programs for strict ISO
C conformance. They soon find that it does not do quite what they want:
it finds some non-ISO practices, but not all---only those for which
ISO C requires a diagnostic, and some others for which
diagnostics have been added.
A feature to report any failure to conform to ISO C might be useful in
some instances, but would require considerable additional work and would
be quite different from -pedantic. We don't have plans to
support such a feature in the near future.
Where the standard specified with -std represents a GNU
extended dialect of C, such as gnu89 or gnu99, there is a
corresponding base standard, the version of ISO C on which the GNU
extended dialect is based. Warnings from -pedantic are given
where they are required by the base standard. (It would not make sense
for such warnings to be given only for features not in the specified GNU
C dialect, since by definition the GNU dialects of C include all
features the compiler supports with the given option, and there would be
nothing to warn about.)
Like -pedantic, except that errors are produced rather than
warnings.
Inhibit all warning messages.
Inhibit warning messages about the use of #import.
Warn if an array subscript has type [C`]char[C']. This is a common cause
of error, as programmers often forget that this type is signed on some
machines.
Warn whenever a comment-start sequence /* appears in a /*
comment, or whenever a Backslash-Newline appears in a // comment.
Check calls to [C`]printf[C'] and [C`]scanf[C'], etc., to make sure that
the arguments supplied have types appropriate to the format string
specified, and that the conversions specified in the format string make
sense. This includes standard functions, and others specified by format
attributes, in the [C`]printf[C'],
[C`]scanf[C'], [C`]strftime[C'] and [C`]strfmon[C'] (an X/Open extension,
not in the C standard) families.
The formats are checked against the format features supported by GNU
libc version 2.2. These include all ISO C89 and C99 features, as well
as features from the Single Unix Specification and some BSD and GNU
extensions. Other library implementations may not support all these
features; GCC does not support warning about features that go beyond a
particular library's limitations. However, if -pedantic is used
with -Wformat, warnings will be given about format features not
in the selected standard version (but not for [C`]strfmon[C'] formats,
since those are not in any version of the C standard).
-Wformat is included in -Wall. For more control over some
aspects of format checking, the options -Wno-format-y2k,
-Wno-format-extra-args, -Wformat-nonliteral,
-Wformat-security and -Wformat=2 are available, but are
not included in -Wall.
If -Wformat is specified, do not warn about [C`]strftime[C']
formats which may yield only a two-digit year.
If -Wformat is specified, do not warn about excess arguments to a
[C`]printf[C'] or [C`]scanf[C'] format function. The C standard specifies
that such arguments are ignored.
Where the unused arguments lie between used arguments that are
specified with $ operand number specifications, normally
warnings are still given, since the implementation could not know what
type to pass to [C`]va_arg[C'] to skip the unused arguments. However,
in the case of [C`]scanf[C'] formats, this option will suppress the
warning if the unused arguments are all pointers, since the Single
Unix Specification says that such unused arguments are allowed.
If -Wformat is specified, also warn if the format string is not a
string literal and so cannot be checked, unless the format function
takes its format arguments as a [C`]va_list[C'].
If -Wformat is specified, also warn about uses of format
functions that represent possible security problems. At present, this
warns about calls to [C`]printf[C'] and [C`]scanf[C'] functions where the
format string is not a string literal and there are no format arguments,
as in [C`]printf (foo);[C']. This may be a security hole if the format
string came from untrusted input and contains %n. (This is
currently a subset of what -Wformat-nonliteral warns about, but
in future warnings may be added to -Wformat-security that are not
included in -Wformat-nonliteral.)
Enable -Wformat plus format checks not included in
-Wformat. Currently equivalent to -Wformat
-Wformat-nonliteral -Wformat-security.
Warn when a declaration does not specify a type.
Give a warning (or error) whenever a function is used before being
declared.
Same as -Wimplicit-int and -Wimplicit-function-declaration.
Warn if the type of main is suspicious. main should be a
function with external linkage, returning int, taking either zero
arguments, two, or three arguments of appropriate types.
Warn if an aggregate or union initializer is not fully bracketed. In
the following example, the initializer for a is not fully
bracketed, but that for b is fully bracketed.
int a[2][2] = { 0, 1, 2, 3 };
int b[2][2] = { { 0, 1 }, { 2, 3 } };
Warn if parentheses are omitted in certain contexts, such
as when there is an assignment in a context where a truth value
is expected, or when operators are nested whose precedence people
often get confused about.
Also warn about constructions where there may be confusion to which
[C`]if[C'] statement an [C`]else[C'] branch belongs. Here is an example of
such a case:
{
if (a)
if (b)
foo ();
else
bar ();
}
In C, every [C`]else[C'] branch belongs to the innermost possible [C`]if[C']
statement, which in this example is [C`]if (b)[C']. 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 will issue a warning when this flag is specified.
To eliminate the warning, add explicit braces around the innermost
[C`]if[C'] statement so there is no way the [C`]else[C'] could belong to
the enclosing [C`]if[C']. The resulting code would look like this:
{
if (a)
{
if (b)
foo ();
else
bar ();
}
}
Warn about code that may have undefined semantics because of violations
of sequence point rules in the C standard.
The C standard defines the order in which expressions in a 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
[C`]&&[C'], [C`]||[C'], [C`]? :[C'] or [C`],[C'] (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 standard specifies 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 [C`]a = a++;[C'], [C`]a[n]
= b[n++][C'] and [C`]a[i++] = i;[C']. 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 present implementation of this option only works for C programs. A
future implementation may also work for [C+] programs.
The C standard is worded confusingly, therefore there is some debate
over the precise meaning of the sequence point rules in subtle cases.
Links to discussions of the problem, including proposed formal
definitions, may be found on our readings page, at
<http://gcc.gnu.org/readings.html>.
Warn whenever a function is defined with a return-type that defaults to
[C`]int[C']. Also warn about any [C`]return[C'] statement with no
return-value in a function whose return-type is not [C`]void[C'].
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.
Warn whenever a [C`]switch[C'] statement has an index of enumeral type
and lacks a [C`]case[C'] for one or more of the named codes of that
enumeration. (The presence of a [C`]default[C'] label prevents this
warning.) [C`]case[C'] labels outside the enumeration range also
provoke warnings when this option is used.
Warn if any trigraphs are encountered that might change the meaning of
the program (trigraphs within comments are not warned about).
Warn whenever a static function is declared but not defined or a
non\-inline static function is unused.
Warn whenever a label is declared but not used.
To suppress this warning use the unused attribute.
Warn whenever a function parameter is unused aside from its declaration.
To suppress this warning use the unused attribute.
Warn whenever a local variable or non-constant static variable is unused
aside from its declaration
To suppress this warning use the unused attribute.
Warn whenever a statement computes a result that is explicitly not used.
To suppress this warning cast the expression to void.
All all the above -Wunused options combined.
In order to get a warning about an unused function parameter, you must
either specify -W -Wunused or separately specify
-Wunused-parameter.
Warn if an automatic variable is used without first being initialized or
if a variable may be clobbered by a [C`]setjmp[C'] call.
These warnings are possible only in optimizing compilation,
because they require data flow information that is computed only
when optimizing. If you don't specify -O, you simply won't
get these warnings.
These warnings occur only for variables that are candidates for
register allocation. Therefore, they do not occur for a variable that
is declared [C`]volatile[C'], or whose address is taken, or whose size
is other than 1, 2, 4 or 8 bytes. Also, they do not occur for
structures, unions or arrays, even when they are in registers.
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.
These warnings are made optional because GCC is not smart
enough to see all the reasons why the code might be correct
despite appearing to have an error. Here is one example of how
this can happen:
{
int x;
switch (y)
{
case 1: x = 1;
break;
case 2: x = 4;
break;
case 3: x = 5;
}
foo (x);
}
If the value of [C`]y[C'] is always 1, 2 or 3, then [C`]x[C'] is
always initialized, but GCC doesn't know this. Here is
another common case:
{
int save_y;
if (change_y) save_y = y, y = new_y;
...
if (change_y) y = save_y;
}
This has no bug because [C`]save_y[C'] is used only if it is set.
This option also warns when a non-volatile automatic variable might be
changed by a call to [C`]longjmp[C']. These warnings as well are possible
only in optimizing compilation.
The compiler sees only the calls to [C`]setjmp[C']. It cannot know
where [C`]longjmp[C'] 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 [C`]longjmp[C'] cannot
in fact be called at the place which would cause a problem.
Some spurious warnings can be avoided if you declare all the functions
you use that never return as [C`]noreturn[C'].
Warn when the order of member initializers given in the code does not
match the order in which they must be executed. For instance:
Warn when a #pragma directive is encountered which is not understood by
GCC. If this command line option is used, warnings will even be issued
for unknown pragmas in system header files. This is not the case if
the warnings were only enabled by the -Wall command line option.
All of the above -W options combined. This enables all the
warnings about constructions that some users consider questionable, and
that are easy to avoid (or modify to prevent the warning), even in
conjunction with macros.
Warn about compile-time integer division by zero. This is default. To
inhibit the warning messages, use -Wno-div-by-zero. Floating
point division by zero is not warned about, as it can be a legitimate
way of obtaining infinities and NaNs.
Warn if a multicharacter constant ('FOOF') is used. This is
default. To inhibit the warning messages, use -Wno-multichar.
Usually they indicate a typo in the user's code, as they have
implementation-defined values, and should not be used in portable code.
Print warning messages for constructs found in system header files.
Warnings from system headers are normally suppressed, on the assumption
that they usually do not indicate real problems and would only make the
compiler output harder to read. Using this command line option tells
GCC to emit warnings from system headers as if they occurred in user
code. However, note that using -Wall in conjunction with this
option will not warn about unknown pragmas in system
headers---for that, -Wunknown-pragmas must also be used.
The following -W... options are not implied by -Wall. Some of them warn about constructions that users generally do not consider questionable, but which occasionally you might wish to check for; others warn about constructions that are necessary or hard to avoid in some cases, and there is no simple way to modify the code to suppress the warning. Print extra warning messages for these events:
Options of the form -fflag specify machine-independent
flags. Most flags have both positive and negative forms; the negative
form of -ffoo would be -fno-foo. In the table below,
only one of the forms is listed---the one which is not the default.
You can figure out the other form by either removing no- or
adding it.
Do not store floating point variables in registers, and inhibit other
options that might change whether a floating point value is taken from a
register or memory.
This option prevents undesirable excess precision on machines such as
the 68000 where the floating registers (of the 68881) keep more
precision than a [C`]double[C'] is supposed to have. Similarly for the
x86 architecture. For most programs, the excess precision does only
good, but a few programs rely on the precise definition of IEEE floating
point. Use -ffloat-store for such programs, after modifying
them to store all pertinent intermediate computations into variables.
Do not make member functions inline by default merely because they are
defined inside the class scope ([C+] only). Otherwise, when you specify
-O, member functions defined inside class scope are compiled
inline by default; i.e., you don't need to add inline in front of
the member function name.
Always pop the arguments to each function call as soon as that function
returns. For machines which must pop arguments after a function call,
the compiler normally lets arguments accumulate on the stack for several
function calls and pops them all at once.
Force memory operands to be copied into registers before doing
arithmetic on them. This produces better code by making all memory
references potential common subexpressions. When they are not common
subexpressions, instruction combination should eliminate the separate
register-load. The -O2 option turns on this option.
Force memory address constants to be copied into registers before
doing arithmetic on them. This may produce better code just as
-fforce-mem may.
Don't keep the frame pointer in a register for functions that
don't need one. This avoids the instructions to save, set up and
restore frame pointers; it also makes an extra register available
in many functions. It also makes debugging impossible on
some machines.
On some machines, such as the VAX, this flag has no effect, because
the standard calling sequence automatically handles the frame pointer
and nothing is saved by pretending it doesn't exist. The
machine-description macro [C`]FRAME_POINTER_REQUIRED[C'] controls
whether a target machine supports this flag.
Optimize sibling and tail recursive calls.
This option generates traps for signed overflow on addition, subtraction,
multiplication operations.
Don't pay attention to the [C`]inline[C'] keyword. Normally this option
is used to keep the compiler from expanding any functions inline.
Note that if you are not optimizing, no functions can be expanded inline.
Integrate all simple functions into their callers. The compiler
heuristically decides which functions are simple enough to be worth
integrating in this way.
If all calls to a given function are integrated, and the function is
declared [C`]static[C'], then the function is normally not output as
assembler code in its own right.
By default, gcc limits the size of functions that can be inlined. This flag
allows the control of this limit for functions that are explicitly marked as
inline (ie marked with the inline keyword or defined within the class
definition in c++). n is the size of functions that can be inlined in
number of pseudo instructions (not counting parameter handling). The default
value of n is 600.
Increasing this value can result in more inlined code at
the cost of compilation time and memory consumption. Decreasing usually makes
the compilation faster and less code will be inlined (which presumably
means slower programs). This option is particularly useful for programs that
use inlining heavily such as those based on recursive templates with [C+].
Note: pseudo instruction represents, in this particular context, an
abstract measurement of function's size. In no way, it represents a count
of assembly instructions and as such its exact meaning might change from one
release to an another.
Even if all calls to a given function are integrated, and the function
is declared [C`]static[C'], nevertheless output a separate run-time
callable version of the function. This switch does not affect
[C`]extern inline[C'] functions.
Emit variables declared [C`]static const[C'] when optimization isn't turned
on, even if the variables aren't referenced.
GCC enables this option by default. If you want to force the compiler to
check if the variable was referenced, regardless of whether or not
optimization is turned on, use the -fno-keep-static-consts option.
Attempt to merge identical constants (string constants and floating point
constants) accross compilation units.
This option is default for optimized compilation if assembler and linker
support it. Use -fno-merge-constants to inhibit this behavior.
Attempt to merge identical constants and identical variables.
This option implies -fmerge-constants. In addition to
-fmerge-constants this considers e.g. even constant initialized
arrays or initialized constant variables with integral or floating point
types. Languages like C or [C+] require each non-automatic variable to
have distinct location, so using this option will result in non-conforming
behavior.
Do not use ``decrement and branch'' instructions on a count register,
but instead generate a sequence of instructions that decrement a
register, compare it against zero, then branch based upon the result.
This option is only meaningful on architectures that support such
instructions, which include x86, PowerPC, IA-64 and S/390.
Do not put function addresses in registers; make each instruction that
calls a constant function contain the function's address explicitly.
This option results in less efficient code, but some strange hacks
that alter the assembler output may be confused by the optimizations
performed when this option is not used.
Sets -fno-math-errno, -funsafe-math-optimizations, and -fno-trapping-math.
This option causes the preprocessor macro [C`]__FAST_MATH__[C'] to be defined.
This option should never be turned on by any -O option since
it can result in incorrect output for programs which depend on
an exact implementation of IEEE or ISO rules/specifications for
math functions.
Do not set ERRNO after calling math functions that are executed
with a single instruction, e.g., sqrt. A program that relies on
IEEE exceptions for math error handling may want to use this flag
for speed while maintaining IEEE arithmetic compatibility.
This option should never be turned on by any -O option since
it can result in incorrect output for programs which depend on
an exact implementation of IEEE or ISO rules/specifications for
math functions.
The default is -fmath-errno.
Allow optimizations for floating-point arithmetic that (a) assume
that arguments and results are valid and (b) may violate IEEE or
ANSI standards. When used at link-time, it may include libraries
or startup files that change the default FPU control word or other
similar optimizations.
This option should never be turned on by any -O option since
it can result in incorrect output for programs which depend on
an exact implementation of IEEE or ISO rules/specifications for
math functions.
The default is -fno-unsafe-math-optimizations.
Compile code assuming that floating-point operations cannot generate
user-visible traps. Setting this option may allow faster code
if one relies on ``non-stop'' IEEE arithmetic, for example.
This option should never be turned on by any -O option since
it can result in incorrect output for programs which depend on
an exact implementation of IEEE or ISO rules/specifications for
math functions.
The default is -ftrapping-math.
For front-ends that support it, generate additional code to check that
indices used to access arrays are within the declared range. This is
currenly only supported by the Java and Fortran 77 front-ends, where
this option defaults to true and false respectively.
The following options control specific optimizations. The -O2 option turns on all of these optimizations except -funroll-loops and -funroll-all-loops. On most machines, the -O option turns on the -fthread-jumps and -fdelayed-branch options, but specific machines may handle it differently.
You can use the following flags in the rare cases when ``fine-tuning'' of optimizations to be performed is desired.
Not all of the optimizations performed by GCC have -f options
to control them.
Perform the optimizations of loop strength reduction and
elimination of iteration variables.
Perform optimizations where we check to see if a jump branches to a
location where another comparison subsumed by the first is found. If
so, the first branch is redirected to either the destination of the
second branch or a point immediately following it, depending on whether
the condition is known to be true or false.
In common subexpression elimination, scan through jump instructions
when the target of the jump is not reached by any other path. For
example, when CSE encounters an [C`]if[C'] statement with an
[C`]else[C'] clause, CSE will follow the jump when the condition
tested is false.
This is similar to -fcse-follow-jumps, but causes CSE to
follow jumps which conditionally skip over blocks. When CSE
encounters a simple [C`]if[C'] statement with no else clause,
-fcse-skip-blocks causes CSE to follow the jump around the
body of the [C`]if[C'].
Re-run common subexpression elimination after loop optimizations has been
performed.
Run the loop optimizer twice.
Perform a global common subexpression elimination pass.
This pass also performs global constant and copy propagation.
Note: When compiling a program using computed gotos, a GCC
extension, you may get better runtime performance if you disable
the global common subexpression elmination pass by adding
-fno-gcse to the command line.
When -fgcse-lm is enabled, global common subexpression elimination will
attempt to move loads which are only killed by stores into themselves. This
allows a loop containing a load/store sequence to be changed to a load outside
the loop, and a copy/store within the loop.
When -fgcse-sm is enabled, A store motion pass is run after global common
subexpression elimination. This pass will attempt to move stores out of loops.
When used in conjunction with -fgcse-lm, loops containing a load/store sequence
can be changed to a load before the loop and a store after the loop.
Use global dataflow analysis to identify and eliminate useless checks
for null pointers. The compiler assumes that dereferencing a null
pointer would have halted the program. If a pointer is checked after
it has already been dereferenced, it cannot be null.
In some environments, this assumption is not true, and programs can
safely dereference null pointers. Use
-fno-delete-null-pointer-checks to disable this optimization
for programs which depend on that behavior.
Perform a number of minor optimizations that are relatively expensive.
Attempt to reassign register numbers in move instructions and as
operands of other simple instructions in order to maximize the amount of
register tying. This is especially helpful on machines with two-operand
instructions. GCC enables this optimization by default with -O2
or higher.
Note -fregmove and -foptimize-register-move are the same
optimization.
If supported for the target machine, attempt to reorder instructions
to exploit instruction slots available after delayed branch
instructions.
If supported for the target machine, attempt to reorder instructions to
eliminate execution stalls due to required data being unavailable. This
helps machines that have slow floating point or memory load instructions
by allowing other instructions to be issued until the result of the load
or floating point instruction is required.
Similar to -fschedule-insns, but requests an additional pass of
instruction scheduling after register allocation has been done. This is
especially useful on machines with a relatively small number of
registers and where memory load instructions take more than one cycle.
Don't schedule instructions across basic blocks. This is normally
enabled by default when scheduling before register allocation, i.e.
with -fschedule-insns or at -O2 or higher.
Don't allow speculative motion of non-load instructions. This is normally
enabled by default when scheduling before register allocation, i.e.
with -fschedule-insns or at -O2 or higher.
Allow speculative motion of some load instructions. This only makes
sense when scheduling before register allocation, i.e. with
-fschedule-insns or at -O2 or higher.
Allow speculative motion of more load instructions. This only makes
sense when scheduling before register allocation, i.e. with
-fschedule-insns or at -O2 or higher.
Place each function or data item into its own section in the output
file if the target supports arbitrary sections. The name of the
function or the name of the data item determines the section's name
in the output file.
Use these options on systems where the linker can perform optimizations
to improve locality of reference in the instruction space. HPPA
processors running HP-UX and Sparc processors running Solaris 2 have
linkers with such optimizations. Other systems using the ELF object format
as well as AIX may have these optimizations in the future.
Only use these options when there are significant benefits from doing
so. When you specify these options, the assembler and linker will
create larger object and executable files and will also be slower.
You will not be able to use [C`]gprof[C'] on all systems if you
specify this option and you may have problems with debugging if
you specify both this option and -g.
Enable values to be allocated in registers that will be clobbered by
function calls, by emitting extra instructions to save and restore the
registers around such calls. Such allocation is done only when it
seems to result in better code than would otherwise be produced.
This option is always enabled by default on certain machines, usually
those which have no call-preserved registers to use instead.
For all machines, optimization level 2 and higher enables this flag by
default.
Unroll loops whose number of iterations can be determined at compile
time or upon entry to the loop. -funroll-loops implies both
-fstrength-reduce and -frerun-cse-after-loop. This
option makes code larger, and may or may not make it run faster.
Unroll all loops, even if their number of iterations is uncertain when
the loop is entered. This usually makes programs run more slowly.
-funroll-all-loops implies the same options as
-funroll-loops,
If supported by the target machine, generate instructions to prefetch
memory to improve the performance of loops that access large arrays.
Forces all invariant computations in loops to be moved
outside the loop.
Forces all general-induction variables in loops to be
strength-reduced.
Note: When compiling programs written in Fortran,
-fmove-all-movables and -freduce-all-givs are enabled
by default when you use the optimizer.
These options may generate better or worse code; results are highly
dependent on the structure of loops within the source code.
These two options are intended to be removed someday, once
they have helped determine the efficacy of various
approaches to improving loop optimizations.
Please let us (<gcc@gcc.gnu.org> and <fortran@gnu.org>)
know how use of these options affects
the performance of your production code.
We're very interested in code that runs slower
when these options are enabled.
Disable any machine-specific peephole optimizations. The difference
between -fno-peephole and -fno-peephole2 is in how they
are implemented in the compiler; some targets use one, some use the
other, a few use both.
After running a program compiled with -fprofile-arcs, you can compile it a second time using
-fbranch-probabilities, to improve optimizations based on
the number of times each branch was taken. When the program
compiled with -fprofile-arcs exits it saves arc execution
counts to a file called sourcename.da for each source
file The information in this data file is very dependent on the
structure of the generated code, so you must use the same source code
and the same optimization options for both compilations.
With -fbranch-probabilities, GCC puts a REG_EXEC_COUNT
note on the first instruction of each basic block, and a
REG_BR_PROB note on each JUMP_INSN and CALL_INSN.
These can be used to improve optimization. Currently, they are only
used in one place: in reorg.c, instead of guessing which path a
branch is mostly to take, the REG_BR_PROB values are used to
exactly determine which path is taken more often.
Do not guess branch probabilities using a randomized model.
Sometimes gcc will opt to use a randomized model to guess branch
probabilities, when none are available from either profiling feedback
(-fprofile-arcs) or __builtin_expect. This means that
different runs of the compiler on the same program may produce different
object code.
In a hard real-time system, people don't want different runs of the
compiler to produce code that has different behavior; minimizing
non-determinism is of paramount import. This switch allows users to
reduce non-determinism, possibly at the expense of inferior
optimization.
Allows the compiler to assume the strictest aliasing rules applicable to
the language being compiled. For C (and [C+]), this activates
optimizations based on the type of expressions. In particular, an
object of one type is assumed never to reside at the same address as an
object of a different type, unless the types are almost the same. For
example, an [C`]unsigned int[C'] can alias an [C`]int[C'], but not a
[C`]void*[C'] or a [C`]double[C']. A character type may alias any other
type.
Pay special attention to code like this:
union a_union {
int i;
double d;
};
int f() {
a_union t;
t.d = 3.0;
return t.i;
}
The practice of reading from a different union member than the one most
recently written to (called ``type-punning'') is common. Even with
-fstrict-aliasing, type-punning is allowed, provided the memory
is accessed through the union type. So, the code above will work as
expected. However, this code might not:
int f() {
a_union t;
int* ip;
t.d = 3.0;
ip = &t.i;
return *ip;
}
Every language that wishes to perform language-specific alias analysis
should define a function that computes, given an [C`]tree[C']
node, an alias set for the node. Nodes in different alias sets are not
allowed to alias. For an example, see the C front-end function
[C`]c_get_alias_set[C'].
Align the start of functions to the next power-of-two greater than
n, skipping up to n bytes. For instance,
-falign-functions=32 aligns functions to the next 32-byte
boundary, but -falign-functions=24 would align to the next
32-byte boundary only if this can be done by skipping 23 bytes or less.
-fno-align-functions and -falign-functions=1 are
equivalent and mean that functions will not be aligned.
Some assemblers only support this flag when n is a power of two;
in that case, it is rounded up.
If n is not specified, use a machine-dependent default.
Align all branch targets to a power-of-two boundary, skipping up to
n bytes like -falign-functions. This option can easily
make code slower, because it must insert dummy operations for when the
branch target is reached in the usual flow of the code.
If -falign-loops or -falign-jumps are applicable and
are greater than this value, then their values are used instead.
If n is not specified, use a machine-dependent default which is
very likely to be 1, meaning no alignment.
Align loops to a power-of-two boundary, skipping up to n bytes
like -falign-functions. The hope is that the loop will be
executed many times, which will make up for any execution of the dummy
operations.
If n is not specified, use a machine-dependent default.
Align branch targets to a power-of-two boundary, for branch targets
where the targets can only be reached by jumping, skipping up to n
bytes like -falign-functions. In this case, no dummy operations
need be executed.
If n is not specified, use a machine-dependent default.
Perform optimizations in static single assignment form. Each function's
flow graph is translated into SSA form, optimizations are performed, and
the flow graph is translated back from SSA form. Users should not
specify this option, since it is not yet ready for production use.
Perform Sparse Conditional Constant Propagation in SSA form. Requires
-fssa. Like -fssa, this is an experimental feature.
Perform aggressive dead-code elimination in SSA form. Requires -fssa.
Like -fssa, this is an experimental feature.
Treat floating point constant as single precision constant instead of
implicitly converting it to double precision constant.
Attempt to avoid false dependencies in scheduled code by making use
of registers left over after register allocation. This optimization
will most benefit processors with lots of regist