[PATCH] Driver: add target definition for Windows on ARM

[Saleem Abdulrasool]

================
Comment at: lib/Basic/Targets.cpp:4416
@@ +4415,3 @@
+    Builder.defineMacro("__stdcall", "");
+    // The __inline keyword is similar to GNU inline.
+    // http://msdn.microsoft.com/en-us/library/z8y1yy88(v=vs.71).aspx
----------------
Saleem Abdulrasool wrote:
> Reid Kleckner wrote:
> > I'm pretty sure this is wrong.  MSVC's __inline semantics are identical to C++ inline, with an extra quirk for extern __inline, which forces code emission.  Clang handles this in ASTContext::GetGVALinkageForFunction() under -fms-compatibility.  David is working on a patch for 'extern __inline' at the moment.
> > 
> > Perhaps we should change the way this works so that we treat '__inline' as C++ inline in C mode and 'inline' as C99 inline, and the __inline spelling would be enabled by -fms-extensions, which I assume you're using.
> I think that should be controlled by -fms-compatibility no?  -fms-extensions is enabling extensions a la /Ze right?  (BTW, on a separate but related topic, perhaps -fms-compatibility should imply -fms-extensions since /Ze is default?).
> 
> That said, I can double check if __inline can be handled with the work that David did to support it.  If it can, then this can be entirely removed, which is even better!
BTW, an easy way to see the difference in behaviour is:

    clang -cc1 -triple thumbv7-windows -Os -fms-compatibility -S - -o - <<< '__inline int f(int i) { return i + 32; } int g(int i) { return f(i) * 2; }'

With this definition you see label emissions for both f and g, and without only for g.


http://llvm-reviews.chandlerc.com/D3241