This section describes the command-line options that are only meaningful for C++ programs. You can also use most of the GNU compiler options regardless of what language your program is in. For example, you might compile a file firstClass.C
like this:
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:
-fabi-version=
n
Version 0 refers to the version conforming most closely to the C++ ABI specification. Therefore, the ABI obtained using version 0 will change in different versions of G++ as ABI bugs are fixed.
Version 1 is the version of the C++ ABI that first appeared in G++ 3.2.
Version 2 is the version of the C++ ABI that first appeared in G++ 3.4.
Version 3 corrects an error in mangling a constant address as a template argument.
Version 4, which first appeared in G++ 4.5, implements a standard mangling for vector types.
Version 5, which first appeared in G++ 4.6, corrects the mangling of attribute const/volatile on function pointer types, decltype of a plain decl, and use of a function parameter in the declaration of another parameter.
Version 6, which first appeared in G++ 4.7, corrects the promotion behavior of C++11 scoped enums and the mangling of template argument packs, const/static_cast, prefix ++ and –, and a class scope function used as a template argument.
See also -Wabi
.
-fno-access-control
-fcheck-new
operator new
is non-null before attempting to modify the storage allocated. This check is normally unnecessary because the C++ standard specifies that operator new
only returns 0
if it is declared ‘throw()
’, in which case the compiler always checks the return value even without this option. In all other cases, when operator new
has a non-empty exception specification, memory exhaustion is signalled by throwing std::bad_alloc
. See also ‘new (nothrow)
’. -fconstexpr-depth=
n
-fdeduce-init-list
std::initializer_list
from a brace-enclosed initializer list, i.e. template <class T> auto forward(T t) -> decltype (realfn (t)) { return realfn (t); } void f() { forward({1,2}); // call forward<std::initializer_list<int>> }
This deduction was implemented as a possible extension to the originally proposed semantics for the C++11 standard, but was not part of the final standard, so it is disabled by default. This option is deprecated, and may be removed in a future version of G++.
-ffriend-injection
This option is for compatibility, and may be removed in a future release of G++.
-fno-elide-constructors
-fno-enforce-eh-specs
NDEBUG
’. This does not give user code permission to throw exceptions in violation of the exception specifications; the compiler still optimizes based on the specifications, so throwing an unexpected exception results in undefined behavior at run time. -fextern-tls-init
-fno-extern-tls-init
thread_local
’ and ‘threadprivate
’ variables to have dynamic (runtime) initialization. To support this, any use of such a variable goes through a wrapper function that performs any necessary initialization. When the use and definition of the variable are in the same translation unit, this overhead can be optimized away, but when the use is in a different translation unit there is significant overhead even if the variable doesn't actually need dynamic initialization. If the programmer can be sure that no use of the variable in a non-defining TU needs to trigger dynamic initialization (either because the variable is statically initialized, or a use of the variable in the defining TU will be executed before any uses in another TU), they can avoid this overhead with the -fno-extern-tls-init
option. On targets that support symbol aliases, the default is -fextern-tls-init
. On targets that do not support symbol aliases, the default is -fno-extern-tls-init
.
-ffor-scope
-fno-for-scope
-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++. If neither flag is given, the default is to follow the standard, but to allow and give a warning for old-style code that would otherwise be invalid, or have different behavior.
-fno-gnu-keywords
typeof
as a keyword, so that code can use this word as an identifier. You can use the keyword __typeof__
instead. -ansi
implies -fno-gnu-keywords
. -fno-implicit-templates
-fno-implicit-inline-templates
-fno-implement-inlines
#pragma implementation
’. This causes linker errors if these functions are not inlined everywhere they are called. -fms-extensions
-fno-nonansi-builtins
ffs
, alloca
, _exit
, index
, bzero
, conjf
, and other related functions. -fnothrow-opt
throw()
exception specification as if it were a noexcept
specification to reduce or eliminate the text size overhead relative to a function with no exception specification. If the function has local variables of types with non-trivial destructors, the exception specification actually makes the function smaller because the EH cleanups for those variables can be optimized away. The semantic effect is that an exception thrown out of a function with such an exception specification results in a call to terminate
rather than unexpected
. -fno-operator-names
and
, bitand
, bitor
, compl
, not
, or
and xor
as synonyms as keywords. -fno-optional-diags
-fpermissive
-fpermissive
allows some nonconforming code to compile. -fno-pretty-templates
void f(T) [with T = int]
rather than void f(int)
) so that it's clear which template is involved. When an error message refers to a specialization of a class template, the compiler omits any template arguments that match the default template arguments for that template. If either of these behaviors make it harder to understand the error message rather than easier, you can use -fno-pretty-templates
to disable them. -frepo
-fno-implicit-templates
. See Template Instantiation, for more information. -fno-rtti
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 G++ generates it as needed. The ‘dynamic_cast
’ operator can still be used for casts that do not require run-time type information, i.e. casts to void *
or to unambiguous base classes. -fstats
-fstrict-enums
-ftemplate-backtrace-limit=
n
-ftemplate-depth=
n
-fno-threadsafe-statics
-fuse-cxa-atexit
__cxa_atexit
function rather than the atexit
function. This option is required for fully standards-compliant handling of static destructors, but only works if your C library supports __cxa_atexit
. -fno-use-cxa-get-exception-ptr
__cxa_get_exception_ptr
runtime routine. This causes std::uncaught_exception
to be incorrect, but is necessary if the runtime routine is not available. -fvisibility-inlines-hidden
The effect of this is that GCC may, effectively, mark inline methods with __attribute__ ((visibility ("hidden")))
so that they do not appear in the export table of a DSO and do not require a PLT indirection when used within the DSO. Enabling this option can have a dramatic effect on load and link times of a DSO as it massively reduces the size of the dynamic export table when the library makes heavy use of templates.
The behavior of this switch is not quite the same as marking the methods as hidden directly, because it does not affect static variables local to the function or cause the compiler to deduce that the function is defined in only one shared object.
You may mark a method as having a visibility explicitly to negate the effect of the switch for that method. For example, if you do want to compare pointers to a particular inline method, you might mark it as having default visibility. Marking the enclosing class with explicit visibility has no effect.
Explicitly instantiated inline methods are unaffected by this option as their linkage might otherwise cross a shared library boundary. See Template Instantiation.
-fvisibility-ms-compat
The flag makes these changes to GCC's linkage model:
hidden
, like -fvisibility=hidden
. In new code it is better to use -fvisibility=hidden
and export those classes that are intended to be externally visible. Unfortunately it is possible for code to rely, perhaps accidentally, on the Visual Studio behavior.
Among the consequences of these changes are that static data members of the same type with the same name but defined in different shared objects are different, so changing one does not change the other; and that pointers to function members defined in different shared objects may not compare equal. When this flag is given, it is a violation of the ODR to define types with the same name differently.
-fvtable-verify=
std|preinit|none
-fvtable-verify=none
) the security feature that verifies at runtime, for every virtual call that is made, that the vtable pointer through which the call is made is valid for the type of the object, and has not been corrupted or overwritten. If an invalid vtable pointer is detected (at runtime), an error is reported and execution of the program is immediately halted. This option causes runtime data structures to be built, at program start up, for verifying the vtable pointers. The options std
and preinit
control the timing of when these data structures are built. In both cases the data structures are built before execution reaches 'main'. The -fvtable-verify=std
causes these data structure to be built after the shared libraries have been loaded and initialized. -fvtable-verify=preinit
causes them to be built before the shared libraries have been loaded and initialized.
If this option appears multiple times in the compiler line, with different values specified, 'none' will take highest priority over both 'std' and 'preinit'; 'preinit' will take priority over 'std'.
-fvtv-debug
-fvtable-verify=std
or -fvtable-verify=preinit
has been used. This flag will also cause the compiler to keep track of which vtable pointers it found for each class, and record that information in the file “vtv_set_ptr_data.log”, in the dump file directory on the user's machine. Note: This feature APPENDS data to the log file. If you want a fresh log file, be sure to delete any existing one.
-fvtv-counts
-fvtable-verify=std
or -fvtable-verify=preinit
, this causes the compiler to keep track of the total number of virtual calls it encountered and the number of verifications it inserted. It also counts the number of calls to certain runtime library functions that it inserts. This information, for each compilation unit, is written to a file named “vtv_count_data.log”, in the dump_file directory on the user's machine. It also counts the size of the vtable pointer sets for each class, and writes this information to “vtv_class_set_sizes.log” in the same directory. Note: This feature APPENDS data to the log files. To get a fresh log files, be sure to delete any existing ones.
-fno-weak
-nostdinc++
In addition, these optimization, warning, and code generation options have meanings only for C++ programs:
-Wabi
(C, Objective-C, C++ and Objective-C++ only)
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 incompatibilities in -fabi-version=2
(the default) include:
extern int N; template <int &> struct S {}; void n (S<N>) {2}
This is fixed in -fabi-version=3
.
__attribute ((vector_size))
are mangled in a non-standard way that does not allow for overloading of functions taking vectors of different sizes. The mangling is changed in -fabi-version=4
.
The known incompatibilities in -fabi-version=1
include:
struct A { virtual void f(); int f1 : 1; }; struct B : public A { int f2 : 1; };
In this case, G++ places B::f2
into the same byte as A::f1
; other compilers do not. You can avoid this problem by explicitly padding A
so that its size is a multiple of the byte size on your platform; that causes G++ and other compilers to lay out B
identically.
struct A { virtual void f(); char c1; }; struct B { B(); char c2; }; struct C : public A, public virtual B {};
In this case, G++ does not place B
into the tail-padding for A
; other compilers do. You can avoid this problem by explicitly padding A
so that its size is a multiple of its alignment (ignoring virtual base classes); that causes G++ and other compilers to lay out C
identically.
union U { int i : 4096; };
Assuming that an int
does not have 4096 bits, G++ makes the union too small by the number of bits in an int
.
struct A {}; struct B { A a; virtual void f (); }; struct C : public B, public A {};
G++ places the A
base class of C
at a nonzero offset; it should be placed at offset zero. G++ mistakenly believes that the A
data member of B
is already at offset zero.
typename
or template template parameters can be mangled incorrectly. template <typename Q> void f(typename Q::X) {} template <template <typename> class Q> void f(typename Q<int>::X) {}
Instantiations of these templates may be mangled incorrectly.
It also warns about psABI-related changes. The known psABI changes at this point include:
long double
members are passed in memory as specified in psABI. For example: union U { long double ld; int i; };
union U
is always passed in memory.
-Wctor-dtor-privacy
(C++ and Objective-C++ only)
-Wdelete-non-virtual-dtor
(C++ and Objective-C++ only)
delete
’ is used to destroy an instance of a class that has virtual functions and non-virtual destructor. It is unsafe to delete an instance of a derived class through a pointer to a base class if the base class does not have a virtual destructor. This warning is enabled by -Wall
. -Wliteral-suffix
(C++ and Objective-C++ only)
<inttypes.h>
. For example: #define __STDC_FORMAT_MACROS #include <inttypes.h> #include <stdio.h> int main() { int64_t i64 = 123; printf("My int64: %"PRId64"\n", i64); }
In this case, PRId64
is treated as a separate preprocessing token.
This warning is enabled by default.
-Wnarrowing
(C++ and Objective-C++ only)
{ }
’, e.g. int i = { 2.2 }; // error: narrowing from double to int
This flag is included in -Wall
and -Wc++11-compat
.
With -std=c++11
, -Wno-narrowing
suppresses the diagnostic required by the standard. Note that this does not affect the meaning of well-formed code; narrowing conversions are still considered ill-formed in SFINAE context.
-Wnoexcept
(C++ and Objective-C++ only)
throw()
’ or ‘noexcept
’) but is known by the compiler to never throw an exception. -Wnon-virtual-dtor
(C++ and Objective-C++ only)
-Weffc++
is specified. -Wreorder
(C++ and Objective-C++ only)
struct A { int i; int j; A(): j (0), i (1) { } };
The compiler rearranges the member initializers for ‘i
’ and ‘j
’ to match the declaration order of the members, emitting a warning to that effect. This warning is enabled by -Wall
.
-fext-numeric-literals
(C++ and Objective-C++ only)
-std=c++98
, -std=gnu++98
, -std=gnu++11
, -std=gnu++1y
. This option is off by default for ISO C++11 onwards (-std=c++11
, ...). The following -W...
options are not affected by -Wall
.
-Weffc++
(C++ and Objective-C++ only)
operator=
return a reference to *this
. &&
, ||
, or ,
. This option also enables -Wnon-virtual-dtor
, which is also one of the effective C++ recommendations. However, the check is extended to warn about the lack of virtual destructor in accessible non-polymorphic bases classes too.
When selecting this option, be aware that the standard library headers do not obey all of these guidelines; use ‘grep -v
’ to filter out those warnings.
-Wstrict-null-sentinel
(C++ and Objective-C++ only)
NULL
as sentinel. When compiling only with GCC this is a valid sentinel, as NULL
is defined to __null
. Although it is a null pointer constant rather than a null pointer, it is guaranteed to be of the same size as a pointer. But this use is not portable across different compilers. -Wno-non-template-friend
(C++ and Objective-C++ only)
friend foo(int)
’), the C++ language specification demands that the friend declare or define an ordinary, nontemplate function. (Section 14.5.3). Before G++ implemented explicit specification, unqualified-ids could be interpreted as a particular specialization of a templatized function. Because this non-conforming behavior is no longer the default behavior for G++, -Wnon-template-friend
allows the compiler to check existing code for potential trouble spots and is on by default. This new compiler behavior can be turned off with -Wno-non-template-friend
, which keeps the conformant compiler code but disables the helpful warning. -Wold-style-cast
(C++ and Objective-C++ only)
dynamic_cast
’, ‘static_cast
’, ‘reinterpret_cast
’, and ‘const_cast
’) are less vulnerable to unintended effects and much easier to search for. -Woverloaded-virtual
(C++ and Objective-C++ only)
struct A { virtual void f(); }; struct B: public A { void f(int); };
the A
class version of f
is hidden in B
, and code like:
B* b; b->f();
fails to compile.
-Wno-pmf-conversions
(C++ and Objective-C++ only)
-Wsign-promo
(C++ and Objective-C++ only)
© Free Software Foundation
Licensed under the GNU Free Documentation License, Version 1.3.
https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/C_002b_002b-Dialect-Options.html