How to detect LLVM and its version through #define directives?

Question

The question is quite clear I think. I'm trying to write a compiler detection header to be able to include in the application information on which compiler was used and which version.

This is part of the code I'm using:

/* GNU C Compiler Detection */
#elif defined __GNUC__
    #ifdef __MINGW32__
        #define COMPILER "MinGW GCC %d.%d.%d"
    #else
        #define COMPILER "GCC %d.%d.%d"
    #endif
    #define COMP_VERSION __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__
#endif

Which could be used like this:

printf("  Compiled using " COMPILER "\n", COMP_VERSION);

Is there any way to detect LLVM and its version? And CLANG?

Solution 1

The __llvm__ and __clang__ macros are the official way to check for an LLVM compiler (llvm-gcc or clang) or clang, respectively.

__has_feature and __has_builtin are the recommended way of checking for optional compiler features when using clang, they are documented here.

Note that you can find a list of the builtin compiler macros for gcc, llvm-gcc, and clang using:

echo | clang -dM -E -

This preprocesses an empty string and spits out all macros defined by the compiler.

Solution 2

I cannot find an answer here, only links to answers, so for completeness, here is the answer:

__clang__             // set to 1 if compiler is clang
__clang_major__       // integer: major marketing version number of clang
__clang_minor__       // integer: minor marketing version number of clang
__clang_patchlevel__  // integer: marketing patch level of clang
__clang_version__     // string: full version number

I get currently:

__clang__=1
__clang_major__=3
__clang_minor__=2
__clang_patchlevel__=0
__clang_version__="3.2 (tags/RELEASE_32/final)"

Solution 3

For clang, you shouldn't test its version number, you should check for features you want with feature checking macros.

Solution 4

Snippet from InitPreprocessor.cpp:

  // Compiler version introspection macros.
  DefineBuiltinMacro(Buf, "__llvm__=1");   // LLVM Backend
  DefineBuiltinMacro(Buf, "__clang__=1");  // Clang Frontend

  // Currently claim to be compatible with GCC 4.2.1-5621.
  DefineBuiltinMacro(Buf, "__GNUC_MINOR__=2");
  DefineBuiltinMacro(Buf, "__GNUC_PATCHLEVEL__=1");
  DefineBuiltinMacro(Buf, "__GNUC__=4");
  DefineBuiltinMacro(Buf, "__GXX_ABI_VERSION=1002");
  DefineBuiltinMacro(Buf, "__VERSION__=\"4.2.1 Compatible Clang Compiler\"");

I didn't find any way to get the version of llvm and clang itself, though..

Solution 5

Take a look at the Pre-defined Compiler Macros page, select Compilers->Clang. There is information on many other macros for standards, compilers, libraries, OS, architectures and more.

View more solutions

Comments

[Matt Joiner]

i guess one could for now rely on the claimed GCC versioned supported for the features, and clang/llvm for extensions

[Matt Joiner]

hm, this is a good point. can you provide a link to some official material regarding this?

[osgx]

@Matt Joiner, I think, Chris himself is some official. Cited from his homepage nondot.org/sabre: "I'm the primary author of the LLVM Compiler Infrastructure".

[Matt Joiner]

@osgx: Nevertheless he could provide links and add documentation to increase the usability of his project.

[pqnet]

Note that __GNUC__ is defined even for clang and llvm-gcc.

[pnkfelix]

This doesn't help when working around LLVM bugs. Such as the bug in fastcall support, which was broken circa build 2335 and fixed in build 2336.

[Dirk Eddelbuettel]

Awesome. Just save my bacon too :)

[rubenvb]

You'd still need __clang__ to know the compiler was actually Clang.

[Carl Lindberg]

Actually, for basic feature checking you don't need __clang__; if the __has_feature etc. macros are themselves not defined, then the features are not supported. But for the OP's purpose you would, since that is trying to print out the actual compiler version, and is not testing for features.

[Paul Beusterien]

My specific answer is #if __has_builtin(__builtin_available) github.com/firebase/firebase-ios-sdk/commit/…

[omajid]

Thanks, that's a great sources. Updated link is sourceforge.net/p/predef/wiki/Compilers

[nemequ]

It's worth mentioning that this is unreliable. Vendors (like Apple) release their own versions of clang with these numbers changed to reflect their own version numbers, which have no relationship to the clang version their compiler is based on. If you're using this to try to determine if something is supported, you may end up with false positives or false negatives (depending on whether the vendor's version numbers are greater than or less than clang's).