VS2013 <atomic> not parsing

I have a custom tool that is built using clang 3.8.0. When I #include the tool fails and gives this error message:

1> In file included from C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\atomic:19:
1>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xatomic.h(98,2): error : MS-style inline assembly is not available: Unable to find target for this triple (no targets are registered)
1> __asm
1> ^
1>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xatomic.h(117,2): error : MS-style inline assembly is not available: Unable to find target for this triple (no targets are registered)
1> __asm
1> ^
1>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xatomic.h(140,2): error : MS-style inline assembly is not available: Unable to find target for this triple (no targets are registered)
1> __asm
1> ^
1>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xatomic.h(163,2): error : MS-style inline assembly is not available: Unable to find target for this triple (no targets are registered)
1> __asm
1> ^
1>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xatomic.h(186,2): error : MS-style inline assembly is not available: Unable to find target for this triple (no targets are registered)
1> __asm
1> ^
1> 5 errors generated.

When I run clang-cl against the same file it compiles without a complaint. What would I need to do to get this to work?

You need to initialize LLVM's list of registered targets, so it can find
the appropriate assembler to use to interpret the assembly code. Here's
what Clang does during startup (though you likely only need a subset of
this if you don't care about actually generating code):

#include "llvm/Support/TargetSelect.h"

  llvm::InitializeAllTargets();
  llvm::InitializeAllTargetMCs();
  llvm::InitializeAllAsmPrinters();
  llvm::InitializeAllAsmParsers();

We need to come up with a solution that allows syntax-only tools that don’t link in any LLVM backends to semantically analyze files with MS inline asm.

For a semantic tool, encountering opaque inline asm is probably only worthy of a warning, since skipping inline asm semantic analysis should only lead to a few false positives. In this case, we’re in a system header and they will probably be suppressed. For a tool that generates IR, unparseable inline asm should definitely be an error.

I’m not exactly sure how to rig up the severity level modification, though.