I've run into this issue in the past: LLVM defines __GNUC__, but it can't consume a program GCC can. I'm experiencing it again on Windows: LLVM defines _MSC_VER, but it can't consume the same program VC++ can. The aggravating thing (for me) is we have specialized code paths for LLVM Clang and Apple Clang (different defines due to different version schemes), and we have to fight with the tool to get it to use them.
How do we tell Clang to stop pretending to be other compilers? Is there a switch or option to do it?
The Clang docs discuss the unwanted MS behavior, but they don't say how to stop it:
For compatibility with existing code that compiles with MSVC, clang defines the _MSC_VER and _MSC_FULL_VER macros. These default to the values of 1800 and 180000000 respectively, making clang look like an early release of Visual C++ 2013. The -fms-compatibility-version= flag overrides these values. It accepts a dotted version tuple, such as 19.00.23506. Changing the MSVC compatibility version makes clang behave more like that version of MSVC. For example, -fms-compatibility-version=19 will enable C++14 features and define char16_t and char32_t as builtin types.
__GNUC__ doesn't mean GCC specifically. All compilers that support GNU C extensions define it, including clang and ICC.
The normal way to detect specifically GCC is by excluding other "compatible" compilers
#if defined(__GNUC__) && !defined(__llvm__) && !defined(__INTEL_COMPILER)
#define REAL_GCC __GNUC__ // probably
#endif
The Clang front-end defines __clang__, but other front-ends that use the LLVM back-end also define __llvm__ (e.g. IBM XL C/C++ versions 13.1.1 through 16.1). It might be better to just exclude __clang__ instead of __llvm__, depending on why you want to exclude it. (e.g. for parsing reasons, vs. for optimization reasons like LLVM evaluating __builtin_constant_p() before doing inlining, so it's useless on args of an inline function.)
See also https://sourceforge.net/p/predef/wiki/Compilers/ for a large list.
https://blog.kowalczyk.info/article/j/guide-to-predefined-macros-in-c-compilers-gcc-clang-msvc-etc..html came up in google results, too, but is less complete.
The thing you should be complaining about is that GCC itself doesn't define a GCC-specific macro you can detect, only the version of the GNU dialect of C it supports. (GNU C is a language, GCC is a compiler for that language. GCC's __GNUC_MINOR__ / __GNUC_PATCHLEVEL__ macros conflate the two, unfortunately.)
Clang defines __GNUC__ / __GNUC_MINOR__ / __GNUC_PATCHLEVEL__ according to the version of gcc that it claims full compatibility with. (Probably only for stuff that GCC documentation guarantees will work, not for stuff that happens to work with that version or later of gcc. For GCC itself, documented = supported.
Being accepted by the compiler doesn't imply it's supported and guaranteed for future GCC versions. That might be how clang justifies claiming support for some GNU C versions).
For example, clang 7.0.1 defines GNUC/MINOR/PATCHLEVEL as 4/2/1, i.e. compat with GCC 4.2.1
e.g. from the GCC manual
#define GCC_VERSION (__GNUC__ * 10000 \
+ __GNUC_MINOR__ * 100 \
+ __GNUC_PATCHLEVEL__)
…
/* Test for GCC > 3.2.0 */
#if GCC_VERSION > 30200
If you're testing for a specific GNU C feature that recent GCC supports but recent clang doesn't support (yet), you should probably be doing something like that.
How do we tell Clang to stop pretending to be other compilers?
I don't know how to do that, nor whether it's even do-able. Why do you want to do this? I have the feeling you want to do this to work around a problem, but perhaps there's a better solution.
[On Windows,] LLVM defines _MSC_VER,
Because you're likely using a standard library that's going to check that in order to produce compatible code.
Clang's goal on Windows is not just to produce standalone code that runs on Windows, but code that can be linked with libraries that were compiled with VC++. From the source code's point of view, it should be indistinguishable whether it's being compiled with clang or VC++.
If you want to be able to call into an existing DLL, and its header files check _MSC_VER, you need it set whether you're using VC++ or clang.
but [clang on Windows] can't consume the same program VC++ can.
Clang's capabilities on Windows have improved quite a bit since this question was written. Several major projects now use clang for their Windows versions.
If you find a correct program that VC++ accepts and clang doesn't, please file a bug report. In most cases, this is probably an oversight. There are a small number of features and VC++ extensions that are not implemented in clang-on-Windows because they weren't a high enough priority. If they're a priority for you, please let us know.
