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 -fstrict-enums -O -c firstClass.C
In this example, only -fstrict-enums is an option meant only for C++ programs; you can use the other options with any language supported by GCC.
Some options for compiling C programs, such as -std, are also relevant for C++ programs. See Options Controlling C Dialect.
Here is a list of options that are only for compiling C++ programs:
-fabi-version=nVersion 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, and was the default through G++ 4.9.
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.
Version 7, which first appeared in G++ 4.8, that treats nullptr_t as a builtin type and corrects the mangling of lambdas in default argument scope.
Version 8, which first appeared in G++ 4.9, corrects the substitution behavior of function types with function-cv-qualifiers.
Version 9, which first appeared in G++ 5.2, corrects the alignment of
nullptr_t.
Version 10, which first appeared in G++ 6.1, adds mangling of attributes that affect type identity, such as ia32 calling convention attributes (e.g. ‘stdcall’).
Version 11, which first appeared in G++ 7, corrects the mangling of sizeof... expressions and operator names. For multiple entities with the same name within a function, that are declared in different scopes, the mangling now changes starting with the twelfth occurrence. It also implies -fnew-inheriting-ctors.
Version 12, which first appeared in G++ 8, corrects the calling conventions for empty classes on the x86_64 target and for classes with only deleted copy/move constructors. It accidentally changes the calling convention for classes with a deleted copy constructor and a trivial move constructor.
Version 13, which first appeared in G++ 8.2, fixes the accidental change in version 12.
See also -Wabi.
-fabi-compat-version=nWith -fabi-version=0 (the default), this defaults to 11 (GCC 7 compatibility). If another ABI version is explicitly selected, this defaults to 0. For compatibility with GCC versions 3.2 through 4.9, use -fabi-compat-version=2.
If this option is not provided but -Wabi=n is, that
version is used for compatibility aliases. If this option is provided
along with -Wabi (without the version), the version from this
option is used for the warning.
-fno-access-control-faligned-newnew of types that require more
alignment than void* ::operator new(std::size_t) provides. A
numeric argument such as -faligned-new=32 can be used to
specify how much alignment (in bytes) is provided by that function,
but few users will need to override the default of
alignof(std::max_align_t).
This flag is enabled by default for -std=c++17.
-fcheck-newoperator 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)’.
-fconcepts template <class T> concept bool Addable = requires (T t) { t + t; };
template <Addable T> T add (T a, T b) { return a + b; }
-fconstexpr-depth=n-fconstexpr-loop-limit=n-fdeduce-init-liststd::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-injectionThis option is deprecated and will be removed.
-fno-elide-constructorsIn C++17, the compiler is required to omit these temporaries, but this
option still affects trivial member functions.
-fno-enforce-eh-specsNDEBUG. 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-initthread_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-scopefor 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++.
This option is deprecated and the associated non-standard
functionality will be removed.
-fno-gnu-keywordstypeof as a keyword, so that code can use this
word as an identifier. You can use the keyword __typeof__ instead.
This option is implied by the strict ISO C++ dialects: -ansi,
-std=c++98, -std=c++11, etc.
-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-fnew-inheriting-ctors-fnew-ttp-matching-fno-nonansi-builtinsffs, alloca, _exit,
index, bzero, conjf, and other related functions.
-fnothrow-optthrow() 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-namesand, bitand,
bitor, compl, not, or and xor as
synonyms as keywords.
-fno-optional-diags-fpermissive-fno-pretty-templatesvoid 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-rttidynamic_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.
-fsized-deallocation void operator delete (void *, std::size_t) noexcept;
void operator delete[] (void *, std::size_t) noexcept;
as introduced in C++14. This is useful for user-defined replacement
deallocation functions that, for example, use the size of the object
to make deallocation faster. Enabled by default under
-std=c++14 and above. The flag -Wsized-deallocation
warns about places that might want to add a definition.
-fstrict-enums-fstrong-eval-order-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-hiddenThe 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-compatThe 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.
-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)-Wabi can also be used with an explicit version number to warn about compatibility with a particular -fabi-version level, e.g. -Wabi=2 to warn about changes relative to -fabi-version=2.
If an explicit version number is provided and -fabi-compat-version is not specified, the version number from this option is used for compatibility aliases. If no explicit version number is provided with this option, but -fabi-compat-version is specified, that version number is used for ABI warnings.
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 is 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.
Known incompatibilities in -fabi-version=2 (which was the default from GCC 3.4 to 4.9) include:
extern int N;
template <int &> struct S {};
void n (S<N>) {2}
This was fixed in -fabi-version=3.
__attribute ((vector_size)) were
mangled in a non-standard way that does not allow for overloading of
functions taking vectors of different sizes.
The mangling was changed in -fabi-version=4.
__attribute ((const)) and noreturn were mangled as type
qualifiers, and decltype of a plain declaration was folded away.
These mangling issues were fixed in -fabi-version=5.
va_arg to complain.
On most targets this does not actually affect the parameter passing
ABI, as there is no way to pass an argument smaller than int.
Also, the ABI changed the mangling of template argument packs,
const_cast, static_cast, prefix increment/decrement, and
a class scope function used as a template argument.
These issues were corrected in -fabi-version=6.
nullptr_t.
These issues were corrected in -fabi-version=7.
This was fixed in -fabi-version=8, the default for GCC 5.1.
decltype(nullptr) incorrectly had an alignment of 1, leading to
unaligned accesses. Note that this did not affect the ABI of a
function with a nullptr_t parameter, as parameters have a
minimum alignment.
This was fixed in -fabi-version=9, the default for GCC 5.2.
This was fixed in -fabi-version=10, the default for GCC 6.1.
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.
-Wabi-tag (C++ and Objective-C++ only)-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.
Additionally, warn when a user-defined literal operator is declared with a literal suffix identifier that doesn't begin with an underscore. Literal suffix identifiers that don't begin with an underscore are reserved for future standardization.
This warning is enabled by default.
-Wlto-type-mismatch-Wno-narrowing (C++ and Objective-C++ only)With -Wnarrowing in C++98, warn when a narrowing conversion prohibited by C++11 occurs within ‘{ }’, e.g.
int i = { 2.2 }; // error: narrowing from double to int
This flag is included in -Wall and -Wc++11-compat.
-Wnoexcept (C++ and Objective-C++ only)throw() or noexcept) but is known by
the compiler to never throw an exception.
-Wnoexcept-type (C++ and Objective-C++ only)noexcept part of a function
type changes the mangled name of a symbol relative to C++14. Enabled
by -Wabi and -Wc++17-compat.
As an example:
template <class T> void f(T t) { t(); };
void g() noexcept;
void h() { f(g); }
In C++14, f calls f<void(*)()>, but in
C++17 it calls f<void(*)()noexcept>.
-Wclass-memaccess (C++ and Objective-C++ only)memset or memcpy is an object of class type, and when writing
into such an object might bypass the class non-trivial or deleted constructor
or copy assignment, violate const-correctness or encapsulation, or corrupt
virtual table pointers. Modifying the representation of such objects may
violate invariants maintained by member functions of the class. For example,
the call to memset below is undefined because it modifies a non-trivial
class object and is, therefore, diagnosed. The safe way to either initialize
or clear the storage of objects of such types is by using the appropriate
constructor or assignment operator, if one is available.
std::string str = "abc";
memset (&str, 0, sizeof str);
The -Wclass-memaccess option is enabled by -Wall.
Explicitly casting the pointer to the class object to void * or
to a type that can be safely accessed by the raw memory function suppresses
the warning.
-Wnon-virtual-dtor (C++ and Objective-C++ only)-Wregister (C++ and Objective-C++ only)register storage class specifier, except
when it is part of the GNU Explicit Register Variables extension.
The use of the register keyword as storage class specifier has
been deprecated in C++11 and removed in C++17.
Enabled by default with -std=c++17.
-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)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)-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)-Wtemplates (C++ and Objective-C++ only)-Wmultiple-inheritance (C++ and Objective-C++ only)-Wvirtual-inheritance-Wnamespaces-Wno-terminate (C++ and Objective-C++ only)terminate.