GCC是每個從事Linux，以及嵌入式開發等必備的編譯器，由于幫助手冊較多，這裡使用了分頁的形式進行分享，如下為Ubuntu Server 22.04作業系統平台。
GCC幫助手冊的第6小節，第947~1247行。
947 Objective-C++) that the compiler accepts:
948 -ansi
949 In C mode, this is equivalent to -std=c90. In C++ mode, it is equivalent to -std=c++98.
950 This turns off certain features of GCC that are incompatible with ISO C90 (when compiling C code), or of
951 standard C++ (when compiling C++ code), such as the "asm" and "typeof" keywords, and predefined macros such
952 as "unix" and "vax" that identify the type of system you are using. It also enables the undesirable and
953 rarely used ISO trigraph feature. For the C compiler, it disables recognition of C++ style // comments as
954 well as the "inline" keyword.
955 The alternate keywords "__asm__", "__extension__", "__inline__" and "__typeof__" continue to work despite
956 -ansi. You would not want to use them in an ISO C program, of course, but it is useful to put them in
957 header files that might be included in compilations done with -ansi. Alternate predefined macros such as
958 "__unix__" and "__vax__" are also available, with or without -ansi.
959 The -ansi option does not cause non-ISO programs to be rejected gratuitously. For that, -Wpedantic is
960 required in addition to -ansi.
961 The macro "__STRICT_ANSI__" is predefined when the -ansi option is used. Some header files may notice this
962 macro and refrain from declaring certain functions or defining certain macros that the ISO standard doesn't
963 call for; this is to avoid interfering with any programs that might use these names for other things.
964 Functions that are normally built in but do not have semantics defined by ISO C (such as "alloca" and
965 "ffs") are not built-in functions when -ansi is used.
966 -std=
967 Determine the language standard. This option is currently only supported when compiling C or C++.
968 The compiler can accept several base standards, such as c90 or c++98, and GNU dialects of those standards,
969 such as gnu90 or gnu++98. When a base standard is specified, the compiler accepts all programs following
970 that standard plus those using GNU extensions that do not contradict it. For example, -std=c90 turns off
971 certain features of GCC that are incompatible with ISO C90, such as the "asm" and "typeof" keywords, but
972 not other GNU extensions that do not have a meaning in ISO C90, such as omitting the middle term of a "?:"
973 expression. On the other hand, when a GNU dialect of a standard is specified, all features supported by the
974 compiler are enabled, even when those features change the meaning of the base standard. As a result, some
975 strict-conforming programs may be rejected. The particular standard is used by -Wpedantic to identify
976 which features are GNU extensions given that version of the standard. For example -std=gnu90 -Wpedantic
977 warns about C++ style // comments, while -std=gnu99 -Wpedantic does not.
978 A value for this option must be provided; possible values are
979 c90
980 c89
981 iso9899:1990
982 Support all ISO C90 programs (certain GNU extensions that conflict with ISO C90 are disabled). Same as
983 -ansi for C code.
984 iso9899:199409
985 ISO C90 as modified in amendment 1.
986 c99
987 c9x
988 iso9899:1999
989 iso9899:199x
990 ISO C99. This standard is substantially completely supported, modulo bugs and floating-point issues
991 (mainly but not entirely relating to optional C99 features from Annexes F and G). See
992 <http://gcc.gnu.org/c99status.html> for more information. The names c9x and iso9899:199x are
993 deprecated.
994 c11
995 c1x
996 iso9899:2011
997 ISO C11, the 2011 revision of the ISO C standard. This standard is substantially completely supported,
998 modulo bugs, floating-point issues (mainly but not entirely relating to optional C11 features from
999 Annexes F and G) and the optional Annexes K (Bounds-checking interfaces) and L (Analyzability). The
1000 name c1x is deprecated.
1001 c17
1002 c18
1003 iso9899:2017
1004 iso9899:2018
1005 ISO C17, the 2017 revision of the ISO C standard (published in 2018). This standard is same as C11
1006 except for corrections of defects (all of which are also applied with -std=c11) and a new value of
1007 "__STDC_VERSION__", and so is supported to the same extent as C11.
1008 c2x The next version of the ISO C standard, still under development. The support for this version is
1009 experimental and incomplete.
1010 gnu90
1011 gnu89
1012 GNU dialect of ISO C90 (including some C99 features).
1013 gnu99
1014 gnu9x
1015 GNU dialect of ISO C99. The name gnu9x is deprecated.
1016 gnu11
1017 gnu1x
1018 GNU dialect of ISO C11. The name gnu1x is deprecated.
1019 gnu17
1020 gnu18
1021 GNU dialect of ISO C17. This is the default for C code.
1022 gnu2x
1023 The next version of the ISO C standard, still under development, plus GNU extensions. The support for
1024 this version is experimental and incomplete.
1025 c++98
1026 c++03
1027 The 1998 ISO C++ standard plus the 2003 technical corrigendum and some additional defect reports. Same
1028 as -ansi for C++ code.
1029 gnu++98
1030 gnu++03
1031 GNU dialect of -std=c++98.
1032 c++11
1033 c++0x
1034 The 2011 ISO C++ standard plus amendments. The name c++0x is deprecated.
1035 gnu++11
1036 gnu++0x
1037 GNU dialect of -std=c++11. The name gnu++0x is deprecated.
1038 c++14
1039 c++1y
1040 The 2014 ISO C++ standard plus amendments. The name c++1y is deprecated.
1041 gnu++14
1042 gnu++1y
1043 GNU dialect of -std=c++14. The name gnu++1y is deprecated.
1044 c++17
1045 c++1z
1046 The 2017 ISO C++ standard plus amendments. The name c++1z is deprecated.
1047 gnu++17
1048 gnu++1z
1049 GNU dialect of -std=c++17. This is the default for C++ code. The name gnu++1z is deprecated.
1050 c++20
1051 c++2a
1052 The 2020 ISO C++ standard plus amendments. Support is experimental, and could change in incompatible
1053 ways in future releases. The name c++2a is deprecated.
1054 gnu++20
1055 gnu++2a
1056 GNU dialect of -std=c++20. Support is experimental, and could change in incompatible ways in future
1057 releases. The name gnu++2a is deprecated.
1058 c++2b
1059 c++23
1060 The next revision of the ISO C++ standard, planned for 2023. Support is highly experimental, and will
1061 almost certainly change in incompatible ways in future releases.
1062 gnu++2b
1063 gnu++23
1064 GNU dialect of -std=c++2b. Support is highly experimental, and will almost certainly change in
1065 incompatible ways in future releases.
1066 -fgnu89-inline
1067 The option -fgnu89-inline tells GCC to use the traditional GNU semantics for "inline" functions when in C99
1068 mode.
1069 Using this option is roughly equivalent to adding the "gnu_inline" function attribute to all inline
1070 functions.
1071 The option -fno-gnu89-inline explicitly tells GCC to use the C99 semantics for "inline" when in C99 or
1072 gnu99 mode (i.e., it specifies the default behavior). This option is not supported in -std=c90 or
1073 -std=gnu90 mode.
1074 The preprocessor macros "__GNUC_GNU_INLINE__" and "__GNUC_STDC_INLINE__" may be used to check which
1075 semantics are in effect for "inline" functions.
1076 -fpermitted-flt-eval-methods=style
1077 ISO/IEC TS 18661-3 defines new permissible values for "FLT_EVAL_METHOD" that indicate that operations and
1078 constants with a semantic type that is an interchange or extended format should be evaluated to the
1079 precision and range of that type. These new values are a superset of those permitted under C99/C11, which
1080 does not specify the meaning of other positive values of "FLT_EVAL_METHOD". As such, code conforming to
1081 C11 may not have been written expecting the possibility of the new values.
1082 -fpermitted-flt-eval-methods specifies whether the compiler should allow only the values of
1083 "FLT_EVAL_METHOD" specified in C99/C11, or the extended set of values specified in ISO/IEC TS 18661-3.
1084 style is either "c11" or "ts-18661-3" as appropriate.
1085 The default when in a standards compliant mode (-std=c11 or similar) is -fpermitted-flt-eval-methods=c11.
1086 The default when in a GNU dialect (-std=gnu11 or similar) is -fpermitted-flt-eval-methods=ts-18661-3.
1087 -aux-info filename
1088 Output to the given filename prototyped declarations for all functions declared and/or defined in a
1089 translation unit, including those in header files. This option is silently ignored in any language other
1090 than C.
1091 Besides declarations, the file indicates, in comments, the origin of each declaration (source file and
1092 line), whether the declaration was implicit, prototyped or unprototyped (I, N for new or O for old,
1093 respectively, in the first character after the line number and the colon), and whether it came from a
1094 declaration or a definition (C or F, respectively, in the following character). In the case of function
1095 definitions, a K&R-style list of arguments followed by their declarations is also provided, inside
1096 comments, after the declaration.
1097 -fallow-parameterless-variadic-functions
1098 Accept variadic functions without named parameters.
1099 Although it is possible to define such a function, this is not very useful as it is not possible to read
1100 the arguments. This is only supported for C as this construct is allowed by C++.
1101 -fno-asm
1102 Do not recognize "asm", "inline" or "typeof" as a keyword, so that code can use these words as identifiers.
1103 You can use the keywords "__asm__", "__inline__" and "__typeof__" instead. -ansi implies -fno-asm.
1104 In C++, this switch only affects the "typeof" keyword, since "asm" and "inline" are standard keywords. You
1105 may want to use the -fno-gnu-keywords flag instead, which has the same effect. In C99 mode (-std=c99 or
1106 -std=gnu99), this switch only affects the "asm" and "typeof" keywords, since "inline" is a standard keyword
1107 in ISO C99.
1108 -fno-builtin
1109 -fno-builtin-function
1110 Don't recognize built-in functions that do not begin with __builtin_ as prefix.
1111 GCC normally generates special code to handle certain built-in functions more efficiently; for instance,
1112 calls to "alloca" may become single instructions which adjust the stack directly, and calls to "memcpy" may
1113 become inline copy loops. The resulting code is often both smaller and faster, but since the function
1114 calls no longer appear as such, you cannot set a breakpoint on those calls, nor can you change the behavior
1115 of the functions by linking with a different library. In addition, when a function is recognized as a
1116 built-in function, GCC may use information about that function to warn about problems with calls to that
1117 function, or to generate more efficient code, even if the resulting code still contains calls to that
1118 function. For example, warnings are given with -Wformat for bad calls to "printf" when "printf" is built
1119 in and "strlen" is known not to modify global memory.
1120 With the -fno-builtin-function option only the built-in function function is disabled. function must not
1121 begin with __builtin_. If a function is named that is not built-in in this version of GCC, this option is
1122 ignored. There is no corresponding -fbuiltin-function option; if you wish to enable built-in functions
1123 selectively when using -fno-builtin or -ffreestanding, you may define macros such as:
1124 #define abs(n) __builtin_abs ((n))
1125 #define strcpy(d, s) __builtin_strcpy ((d), (s))
1126 -fgimple
1127 Enable parsing of function definitions marked with "__GIMPLE". This is an experimental feature that allows
1128 unit testing of GIMPLE passes.
1129 -fhosted
1130 Assert that compilation targets a hosted environment. This implies -fbuiltin. A hosted environment is one
1131 in which the entire standard library is available, and in which "main" has a return type of "int".
1132 Examples are nearly everything except a kernel. This is equivalent to -fno-freestanding.
1133 -ffreestanding
1134 Assert that compilation targets a freestanding environment. This implies -fno-builtin. A freestanding
1135 environment is one in which the standard library may not exist, and program startup may not necessarily be
1136 at "main". The most obvious example is an OS kernel. This is equivalent to -fno-hosted.
1137 -fopenacc
1138 Enable handling of OpenACC directives "#pragma acc" in C/C++ and "!$acc" in Fortran. When -fopenacc is
1139 specified, the compiler generates accelerated code according to the OpenACC Application Programming
1140 Interface v2.6 <https://www.openacc.org>. This option implies -pthread, and thus is only supported on
1141 targets that have support for -pthread.
1142 -fopenacc-dim=geom
1143 Specify default compute dimensions for parallel offload regions that do not explicitly specify. The geom
1144 value is a triple of ':'-separated sizes, in order 'gang', 'worker' and, 'vector'. A size can be omitted,
1145 to use a target-specific default value.
1146 -fopenmp
1147 Enable handling of OpenMP directives "#pragma omp" in C/C++ and "!$omp" in Fortran. When -fopenmp is
1148 specified, the compiler generates parallel code according to the OpenMP Application Program Interface v4.5
1149 <https://www.openmp.org>. This option implies -pthread, and thus is only supported on targets that have
1150 support for -pthread. -fopenmp implies -fopenmp-simd.
1151 -fopenmp-simd
1152 Enable handling of OpenMP's SIMD directives with "#pragma omp" in C/C++ and "!$omp" in Fortran. Other
1153 OpenMP directives are ignored.
1154 -fgnu-tm
1155 When the option -fgnu-tm is specified, the compiler generates code for the Linux variant of Intel's current
1156 Transactional Memory ABI specification document (Revision 1.1, May 6 2009). This is an experimental
1157 feature whose interface may change in future versions of GCC, as the official specification changes.
1158 Please note that not all architectures are supported for this feature.
1159 For more information on GCC's support for transactional memory,
1160 Note that the transactional memory feature is not supported with non-call exceptions
1161 (-fnon-call-exceptions).
1162 -fms-extensions
1163 Accept some non-standard constructs used in Microsoft header files.
1164 In C++ code, this allows member names in structures to be similar to previous types declarations.
1165 typedef int UOW;
1166 struct ABC {
1167 UOW UOW;
1168 };
1169 Some cases of unnamed fields in structures and unions are only accepted with this option.
1170 Note that this option is off for all targets except for x86 targets using ms-abi.
1171 -fplan9-extensions
1172 Accept some non-standard constructs used in Plan 9 code.
1173 This enables -fms-extensions, permits passing pointers to structures with anonymous fields to functions
1174 that expect pointers to elements of the type of the field, and permits referring to anonymous fields
1175 declared using a typedef. This is only supported for C, not C++.
1176 -fcond-mismatch
1177 Allow conditional expressions with mismatched types in the second and third arguments. The value of such
1178 an expression is void. This option is not supported for C++.
1179 -flax-vector-conversions
1180 Allow implicit conversions between vectors with differing numbers of elements and/or incompatible element
1181 types. This option should not be used for new code.
1182 -funsigned-char
1183 Let the type "char" be unsigned, like "unsigned char".
1184 Each kind of machine has a default for what "char" should be. It is either like "unsigned char" by default
1185 or like "signed char" by default.
1186 Ideally, a portable program should always use "signed char" or "unsigned char" when it depends on the
1187 signedness of an object. But many programs have been written to use plain "char" and expect it to be
1188 signed, or expect it to be unsigned, depending on the machines they were written for. This option, and its
1189 inverse, let you make such a program work with the opposite default.
1190 The type "char" is always a distinct type from each of "signed char" or "unsigned char", even though its
1191 behavior is always just like one of those two.
1192 -fsigned-char
1193 Let the type "char" be signed, like "signed char".
1194 Note that this is equivalent to -fno-unsigned-char, which is the negative form of -funsigned-char.
1195 Likewise, the option -fno-signed-char is equivalent to -funsigned-char.
1196 -fsigned-bitfields
1197 -funsigned-bitfields
1198 -fno-signed-bitfields
1199 -fno-unsigned-bitfields
1200 These options control whether a bit-field is signed or unsigned, when the declaration does not use either
1201 "signed" or "unsigned". By default, such a bit-field is signed, because this is consistent: the basic
1202 integer types such as "int" are signed types.
1203 -fsso-struct=endianness
1204 Set the default scalar storage order of structures and unions to the specified endianness. The accepted
1205 values are big-endian, little-endian and native for the native endianness of the target (the default).
1206 This option is not supported for C++.
1207 Warning: the -fsso-struct switch causes GCC to generate code that is not binary compatible with code
1208 generated without it if the specified endianness is not the native endianness of the target.
1209 Options Controlling C++ Dialect
1210 This section describes the command-line options that are only meaningful for C++ programs. You can also use
1211 most of the GNU compiler options regardless of what language your program is in. For example, you might
1212 compile a file firstClass.C like this:
1213 g++ -g -fstrict-enums -O -c firstClass.C
1214 In this example, only -fstrict-enums is an option meant only for C++ programs; you can use the other options
1215 with any language supported by GCC.
1216 Some options for compiling C programs, such as -std, are also relevant for C++ programs.
1217 Here is a list of options that are only for compiling C++ programs:
1218 -fabi-version=n
1219 Use version n of the C++ ABI. The default is version 0.
1220 Version 0 refers to the version conforming most closely to the C++ ABI specification. Therefore, the ABI
1221 obtained using version 0 will change in different versions of G++ as ABI bugs are fixed.
1222 Version 1 is the version of the C++ ABI that first appeared in G++ 3.2.
1223 Version 2 is the version of the C++ ABI that first appeared in G++ 3.4, and was the default through G++
1224 4.9.
1225 Version 3 corrects an error in mangling a constant address as a template argument.
1226 Version 4, which first appeared in G++ 4.5, implements a standard mangling for vector types.
1227 Version 5, which first appeared in G++ 4.6, corrects the mangling of attribute const/volatile on function
1228 pointer types, decltype of a plain decl, and use of a function parameter in the declaration of another
1229 parameter.
1230 Version 6, which first appeared in G++ 4.7, corrects the promotion behavior of C++11 scoped enums and the
1231 mangling of template argument packs, const/static_cast, prefix ++ and --, and a class scope function used
1232 as a template argument.
1233 Version 7, which first appeared in G++ 4.8, that treats nullptr_t as a builtin type and corrects the
1234 mangling of lambdas in default argument scope.
1235 Version 8, which first appeared in G++ 4.9, corrects the substitution behavior of function types with
1236 function-cv-qualifiers.
1237 Version 9, which first appeared in G++ 5.2, corrects the alignment of "nullptr_t".
1238 Version 10, which first appeared in G++ 6.1, adds mangling of attributes that affect type identity, such as
1239 ia32 calling convention attributes (e.g. stdcall).
1240 Version 11, which first appeared in G++ 7, corrects the mangling of sizeof... expressions and operator
1241 names. For multiple entities with the same name within a function, that are declared in different scopes,
1242 the mangling now changes starting with the twelfth occurrence. It also implies -fnew-inheriting-ctors.
1243 Version 12, which first appeared in G++ 8, corrects the calling conventions for empty classes on the x86_64
1244 target and for classes with only deleted copy/move constructors. It accidentally changes the calling
1245 convention for classes with a deleted copy constructor and a trivial move constructor.
1246 Version 13, which first appeared in G++ 8.2, fixes the accidental change in version 12.
1247 Version 14, which first appeared in G++ 10, corrects the mangling of the nullptr expression. ![sudo apt-get update 出錯 Updating from such a repository can‘t be done securely, and is therefore[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)