The common predefined macros are GNU C extensions. They are available with the same meanings regardless of the machine or operating system on which you are using GNU C or GNU Fortran. Their names all start with double underscores.
##operator, this provides a convenient means to generate unique identifiers. Care must be taken to ensure that
__COUNTER__is not expanded prior to inclusion of precompiled headers which use it. Otherwise, the precompiled headers will not be used.
__GNUC_MINOR__to 2, and
__GNUC_PATCHLEVEL__to 1. These macros are also defined if you invoke the preprocessor directly.
is new to GCC 3.0; it is also present in the widely-used development snapshots leading up to 3.0 (which identify themselves as GCC 2.96 or 2.97, depending on which snapshot you have).
If all you need to know is whether or not your program is being compiled by GCC, or a non-GCC compiler that claims to accept the GNU C dialects, you can simply test
. If you need to write code which depends on a specific version, you must be more careful. Each time the minor version is increased, the patch level is reset to zero; each time the major version is increased (which happens rarely), the minor version and patch level are reset. If you wish to use the predefined macros directly in the conditional, you will need to write it like this:
/* Test for GCC > 3.2.0 */ #if __GNUC__ > 3 || \ (__GNUC__ == 3 && (__GNUC_MINOR__ > 2 || \ (__GNUC_MINOR__ == 2 && \ __GNUC_PATCHLEVEL__ > 0))
Another approach is to use the predefined macros to calculate a single number, then compare that against a threshold:
#define GCC_VERSION (__GNUC__ * 10000 \ + __GNUC_MINOR__ * 100 \ + __GNUC_PATCHLEVEL__) ... /* Test for GCC > 3.2.0 */ #if GCC_VERSION > 30200
Many people find this form easier to understand.
(__GNUC__ && __cplusplus).
__OPTIMIZE__is defined in all optimizing compilations.
__OPTIMIZE_SIZE__is defined if the compiler is optimizing for size, not speed.
__NO_INLINE__is defined if no functions will be inlined into their callers (when not optimizing, or when inlining has been specifically disabled by -fno-inline ).
These macros cause certain GNU header files to provide optimized definitions, using macros or inline functions, of system library functions. You should not use these macros in any way unless you make sure that programs will execute with the same effect whether or not they are defined. If they are defined, their value is 1.
inlinewill be handled in GCC's traditional gnu90 mode. Object files will contain externally visible definitions of all functions declared
static. They will not contain any definitions of any functions declared
inlinewill be handled according to the ISO C99 standard. Object files will contain externally visible definitions of all functions declared
extern inline. They will not contain definitions of any functions declared
If this macro is defined, GCC supports the
function attribute as a way to always get the gnu90 behavior. Support for this and
was added in GCC 4.1.3. If neither macro is defined, an older version of GCC is being used:
functions will be compiled in gnu90 mode, and the
function attribute will not be recognized.
charis unsigned on the target machine. It exists to cause the standard header file limits.h to work correctly. You should not use this macro yourself; instead, refer to the standard macros defined in limits.h .
__CHAR_UNSIGNED__, this macro is defined if and only if the data type
wchar_tis unsigned and the front-end is in C++ mode.
m68k-aoutenvironment it expands to nothing, but in the
m68k-coffenvironment it expands to a single ‘ % ’.
m68k-aoutenvironment it expands to an ‘ _ ’, but in the
m68k-coffenvironment it expands to nothing.
This macro will have the correct definition even if
is in use, but it will not be correct if target-specific options that adjust this prefix are used (e.g. the OSF/rose
uintptr_ttypedefs, respectively. They exist to make the standard header files stddef.h , stdint.h , and wchar.h work correctly. You should not use these macros directly; instead, include the appropriate headers and use the typedefs. Some of these macros may not be defined on particular systems if GCC does not provide a stdint.h header on those systems.
chardata type. It exists to make the standard header given numerical limits work correctly. You should not use this macro directly; instead, include the appropriate headers.
signed long long,
uintptr_ttypes and to the minimum value of the
sig_atomic_ttypes respectively. They exist to make the standard header given numerical limits work correctly. You should not use these macros directly; instead, include the appropriate headers. Some of these macros may not be defined on particular systems if GCC does not provide a stdint.h header on those systems.
__. They exist the make the implementation of that header work correctly. You should not use these macros directly; instead, include the appropriate headers. Some of these macros may not be defined on particular systems if GCC does not provide a stdint.h header on those systems.
__BYTE_ORDER__is defined to one of the values
__ORDER_PDP_ENDIAN__to reflect the layout of multi-byte and multi-word quantities in memory. If
__BYTE_ORDER__is equal to
__ORDER_BIG_ENDIAN__, then multi-byte and multi-word quantities are laid out identically: the byte (word) at the lowest address is the least significant or most significant byte (word) of the quantity, respectively. If
__BYTE_ORDER__is equal to
__ORDER_PDP_ENDIAN__, then bytes in 16-bit words are laid out in a little-endian fashion, whereas the 16-bit subwords of a 32-bit quantity are laid out in big-endian fashion.
You should use these macros for testing like this:
/* Test for a little-endian machine */ #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
__FLOAT_WORD_ORDER__is defined to one of the values
__ORDER_BIG_ENDIAN__to reflect the layout of the words of multi-word floating-point quantities.
longjmpfor exception handling.
long intand pointer both use 64-bits and
"Sun Sep 16 01:03:52 1973". If the day of the month is less than 10, it is padded with a space on the left.
If GCC cannot determine the current date, it will emit a warning message (once per compilation) and
will expand to
"??? ??? ?? ??:??:?? ????"
fmalbuiltin functions, so that the include file math.h can define the macros
FP_FAST_FMALfor compatibility with the 1999 C standard.
doubleas defined in C99 and C11 Annex F (for example, that the standard rounding modes and exceptions are not supported, or that optimizations are enabled that conflict with IEEE 754 semantics). If 1, it indicates that IEEE 754 arithmetic is intended to be supported; this does not mean that all relevant language features are supported by GCC. If 2 or more, it additionally indicates support for IEEE 754-2008 (in particular, that the binary encodings for quiet and signaling NaNs are as specified in IEEE 754-2008).
This macro does not indicate the default state of command-line options that control optimizations that C99 and C11 permit to be controlled by standard pragmas, where those standards do not require a particular default state. It does not indicate whether optimizations respect signaling NaN semantics (the macro for that is
). It does not indicate support for decimal floating point or the IEEE 754 binary16 and binary128 types.