title: How to tell Clang to stop pretending to be other compilers?
body: <p>I've run into this issue in the past: LLVM defines <a href="https://www.google.com/search?q=&quot;__GNUC__&quot;+LLVM+bug" rel="noreferrer"><code>__GNUC__</code></a>, but it can't consume a program GCC can. I'm experiencing it again on Windows: LLVM defines <a href="https://www.google.com/search?q=LLVM+&quot;_MSC_VER&quot;+bug" rel="noreferrer"><code>_MSC_VER</code></a>, 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.</p>
  
  <p>How do we tell Clang to stop pretending to be other compilers? Is there a switch or option to do it?</p>
  
  <hr>
  
  <p>The Clang docs <a href="http://clang.llvm.org/docs/UsersManual.html" rel="noreferrer">discuss the unwanted MS behavior</a>, but they don't say how to stop it:</p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>