Compilers - natefoo/predef GitHub Wiki

Please submit updates/corrections via the process described on the wiki home page.

Notice that the __ARMCC_VERSION macro is also used as version indicator for Norcroft C, but that the format is different.

Notice that clang also defines the GNU C version macros, but you should use the clang feature checking macros to detect the availability of various features.

The values of the __clang_major__, __clang_minor__, and __clang_patchlevel__ macros are not consistent across distributions of the Clang compiler. For example, the Clang 3.1 distribution available at http://clang.llvm.org defines __clang_major__ and __clang_minor__ as 3 and 1 respectively. The version of Clang distributed with Apple XCode 4.4 is branded as "Apple Clang 4.0" and derives from the open source Clang 3.1 distribution, but defines these macros with the values 4 and 0 respectively. Apple's Clang distribution can be identified by the presence of the __apple_build_version__ macro.

Notice that the meaning of the __GNUC__ macro has changed subtly over the years, from identifying the GNU C/C++ compiler to identifying any compiler that implements the GNU compiler extensions (see the Feature request - a macro defined for GCC discussion for further information). For example, the Intel C++ on Linux also defines these macros from version 8.1 (see the Intel C++ Compiler 8.1 for Linux Release Notes and Intel Compilers for Linux: Compatibility with GNU Compilers.)

If you prefer a single version macro, you can define the following yourself.

#if defined(__GNUC__)
# if defined(__GNUC_PATCHLEVEL__)
#  define __GNUC_VERSION__ (__GNUC__ * 10000 \
                            + __GNUC_MINOR__ * 100 \
                            + __GNUC_PATCHLEVEL__)
# else
#  define __GNUC_VERSION__ (__GNUC__ * 10000 \
                            + __GNUC_MINOR__ * 100)
# endif
#endif

The format of this new macro is:

Notice that the z/OS C/C++ compiler also defines __IBMC__ and __IBMCPP__ macros, but with a different syntax. See the entry on the z/OS C/C++ compiler below for further information.

This is the XL C/C++ compiler for mainframes (e.g. z/OS). The entry on XL C/C++ has been split into two for clarity.

Notice that XL C/C++ also defines __IBMC__ and __IBMCPP__ macros, but with a different syntax. You can use __xlC__ (only defined for XL C/C++) or __COMPILER_VER__ (only defined for z/OS C/C++) to distinguish between the two. Alternatively, the macro identifying z/OS (__MVS__) can be used to distinguish between them.

#if defined(__IBMC__) || defined(__IBMCPP__)
# if defined(__COMPILER_VER__)
/* z/OS C/C++ so __IBMC__ is defined as NVRRM */
# else
/* XL C/C++ so __IBMC__ is defined as VRP */
# endif
#endif

MinGW (formerly known as MinGW32) is a toolchain for creating 32 Bit Windows executables. The MinGW-w64 projects offers toolchains for creating 32 Bit and 64 Bit Windows executables. The following table shows which macros are defined by each toolchain:

Notice that __MINGW32_MAJOR_VERSION, __MINGW32_MINOR_VERSION, __MINGW64_VERSION_MAJOR, and __MINGW64_VERSION_MINOR are only defined if appropriate headers are included. Appropriate headers are <stdlib.h>, <stdio.h>, <windows.h>, <windef.h>, and probably more.

Notice that __ARMCC_VERSION is assigned a floating-point number, so it cannot be used by the preprocessor to compare versions.

Notice that __OPENCC_PATCHLEVEL__ can be a floating-point number (e.g. 5.2 for Open64 version 4.2.5.2) so it cannot be used by the preprocessor to compare patch-levels.

The name of Oracle Solaris Studio has changed over the years (e.g. Sun Studio, Sun Workshop, Forte Developer) but we do not make this distinction in the table above.

Notice that Watcom C++ became Open Watcom C++ after version 11.0, and the official version numbering (but not the version macro) was restated at version 1.0.