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

[David Majnemer]

================
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:
> 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.


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