[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
----------------
David Majnemer wrote:
> Saleem Abdulrasool wrote:
> > 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.
> First of all, this has nothing at all to do with `__inline`. `_inline` and `inline` are both equally affected.
> Second of all, this has nothing at all to do with ARM, X64 and X86 are both equally affected.
> Third of all, this macro definition of `__inline` will give `f` a strong definition, which is definitely wrong.
> 
> It appears that the right thing to do is make `ASTContext::GetGVALinkageForFunction` select `GVA_StrongODR` instead of `GVA_CXXInline` if we respect `/Zc:inline-`
> 
> However, this is all very dubious.
I didnt realise that inline and _inline/__inline behaved similarly in this regard.  However, you are absolutely correct on the point that this is not ARM specific, and that this is not the exactly the same semantics and should be split up, which I will do.


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