[PATCH] Only provide MS builtins when -fms-extensions is on

[Richard Smith]

  I don't have a strong objection to suppressing the MS builtins in GNU mode, and the argument for suppressing `_alloca` seems stronger than for other builtins (even though that name is reserved at global scope too). The inconsistent handling of the GNU versus MS builtins seems weird to me, though (I don't want us to end up with the MS support being a second-class citizen in the long term).

  I think by going in this direction, we are (de facto) claiming the `__builtin_*` builtins as being clang builtins (rather than GNU builtins) that just happen to share a name and semantics with GCC's builtins. This doesn't seem like an untenable position, though we might want to mark some of the more heinous GNU `__builtin_*`s as `LANG_BUILTIN(..., ALL_GNU_LANGUAGES)`.


================
Comment at: include/clang/Basic/Builtins.def:674
@@ +673,3 @@
+// Microsoft builtins.  These are only active with -fms-extensions.
+// They are not library builtins despire our use of LIBBUILTIN.
+LIBBUILTIN(__assume,     "vb",  "n", 0, ALL_MS_LANGUAGES)
----------------
Reid Kleckner wrote:
> Richard Smith wrote:
> > This isn't particularly great. Can you find a cleaner approach? Maybe:
> > 
> >   #ifndef RESTRICTED_BUILTIN
> >   #define RESTRICTED_BUILTIN(a, b, c, d) BUILTIN(a, b, c)
> >   #endif
> > 
> > ... and then explicitly handle this in the one place where we care (in Builtins.cpp)? (Better macro name welcome!)
> Sure.  LANG_BUILTIN(), since its a builtin plus a language restriction?
Works for me.


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