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. Their names all start with double underscores.
__GNUC_MINOR__to 2, and
__GNUC_PATCHLEVEL__to 1. These macros are also defined if you invoke the preprocessor directly.
__GNUC_PATCHLEVEL__ 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
__GNUC__. 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
/* 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 gnu89 mode. In this mode an
extern inlinefunction will never be compiled as a standalone function, and an
inlinefunction which is neither
staticwill always be compiled as a standalone function.
inlinewill be handled according to the ISO C99 standard. In this mode an
extern inlinefunction will always be compiled as a standalone externally visible function, and an
inlinefunction which is neither
staticwill never be compiled as a standalone function.
If this macro is defined, GCC supports the
attribute as a way to always get the gnu89 behaviour. Support for
__GNUC_GNU_INLINE__ was added in GCC 4.1.3. If
neither macro is defined, an older version of GCC is being used:
inline functions will be compiled in gnu89 mode, and the
gnu_inline 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
-f(no-)underscores is in use, but it will not be correct if
target-specific options that adjust this prefix are used (e.g. the
OSF/rose -mno-underscores option).
uintmax_ttypedefs, respectively. They exist to make the standard header files stddef.h and wchar.h work correctly. You should not use these macros directly; instead, include the appropriate headers and use the typedefs.
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, and
intmax_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.
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
__TIMESTAMP__ will expand to
"??? ??? ?? ??:??:?? ????".