[cfe-commits] [PATCH RFC] Stop defining __GNUC__ for MSVC builds

[J B]

I definitely don't want __GNUC__ defined in MS compat mode.  I also have
code (some of it in open source libraries) that would have a conflict here.

I imagine there are different use cases.  My use case is that I want to be
able to use clang to parse, traverse and rewrite my code in a one-off
fashion, but ultimately will still be using MSVC to build.  I really don't
want to have to make manual compensating changes (many of them in open
source libraries) across thousands of files, in order to be able to use
clang to make automatic changes across thousands of files.

Jay

On Tue, Mar 6, 2012 at 8:31 AM, Aaron Ballman <aaron at aaronballman.com>wrote:

> On Mon, Mar 5, 2012 at 10:32 PM, Douglas Gregor <dgregor at apple.com> wrote:
> >
> > On Mar 2, 2012, at 4:16 PM, Aaron Ballman wrote:
> >
> >> There are a lot of references on the web which relate __GNUC__ to GCC
> >> for compiler discovery
> >> (<
> http://sourceforge.net/apps/mediawiki/predef/index.php?title=Compilers#GCC_C.2FC.2B.2B
> >,
> >> <http://www.ocf.berkeley.edu/~pad/tigcc/doc/html/cpp_SEC15_GNUC.html>,
> >> etc).  This translates into a fair number of cross-compiler projects
> >> with code like this:
> >>
> >> #if defined(__GNUC__)
> >>  // Do GCC things
> >> #elif defined(_MSC_VER)
> >>  // Do MSVC things
> >> ...
> >> #endif
> >>
> >> This currently leads to problems when compiling with Clang because
> >> __GNUC__ (and friends) are always defined, even when compiling for MS
> >> compatibility (PR 11790).  I've attached a patch which addresses this
> >> by only defining __GNUC__ et al when MSVC mode is not set.  This means
> >> code like the above will work as expected.
> >>
> >> Thoughts?
> >
> > -  // Currently claim to be compatible with GCC 4.2.1-5621.
> > -  Builder.defineMacro("__GNUC_MINOR__", "2");
> > -  Builder.defineMacro("__GNUC_PATCHLEVEL__", "1");
> > -  Builder.defineMacro("__GNUC__", "4");
> > -  Builder.defineMacro("__GXX_ABI_VERSION", "1002");
> > +  if (!LangOpts.MSCVersion) {
> >
> > This should probably just check LangOpts.MicrosoftMode.
> >
> > I'm not sure about the general approach, though. Even when compiling in
> Microsoft-compatible mode, Clang is still much more GCC-like than
> MSVC-like. I would venture a guess that
> >
> >        // Do GCC things
> >
> > is far more likely to be standards-conforming code that Clang will
> accept than
> >
> >        // Do MSVC things
> >
> > especially when dealing with template libraries in C++.
>
> I think your guess may be off base.  A lot of those things are
> includes.  At work, we have several sources like:
>
> #if defined( _MSC_VER )
> #include <Windows.h>
> #elif defined( __GNUC__ )
> #include <gtk/gtk.h>
> #endif
>
> I think the correct thing to do is define __clang__ and MSVC in
> MS-compat mode, like we already do for __clang__ and __GNUC__ for GNU
> mode.  It seems like a reasonable pattern.  If someone cares about
> clang, that's turned on appropriately, as is the compiler they're
> emulating.
>
> But I do wonder what should happen with -std=gnu++98
> -fms-compatibility as a combination.  Seems almost like an error?
>
> ~Aaron
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120306/7ca1ee79/attachment.html>