[cfe-dev] [RFC] Bump up clang's __GNUC_MINOR__

[Chandler Carruth]

I have previously objected because I worry about getting sucked into
busy-work trying to support "just one more" GCC extension. Also, I think
that eventually projects will need to start using clang-specific
preprocessor guards to enable features.

That said, today I'm a lot less nervous about the "just one more" extension
thing -- partly because we're already stuck in that cycle, and partly
because we've got a lot more contributors so it seems less scary to have to
keep up.

I think I'm down with the change as well, but I'd like to carefully
document what we mean by the emulation so when we get questions (as I have
repeatedly in the past) of the form: "Why does Clang claim to support GCC
4.X.Y when it doesn't support feature Foo?" Essentially I think we should
state that Clang is acting as a subset of a "modern" GCC, supporting most
but not all of its features. Then folks can guard with Clang-specific
macros if they need to differentiate that subset.

On Sat, May 12, 2012 at 11:32 AM, Chris Lattner <clattner at apple.com> wrote:

> Makes sense to me, we should do this early in the release cycle though (ie
> soon).
>
> -Chris
>
> On May 12, 2012, at 6:22 AM, Benjamin Kramer <benny.kra at googlemail.com>
> wrote:
>
> > When clang was invented as a gcc-compatible compiler it started to pose
> as the latest Apple GCC that was available at the time: GCC 4.2.1. This
> made a lot of sense because features from newer GCC versions were missing
> and 4.2-level code got the most testing. However, GCC 4.2.1 was released in
> 2007 and GCC development hasn't stalled since, with clang following suit
> (and inventing new features). This lead to a weird disparity between "only
> gcc 4.2" and "awesome new features".
> >
> > A few examples:
> > * __builtin_bswap (added in GCC 4.3) and __builtin_unreachable (GCC 4.5)
> are two builtins that are primarily used for optimization. Portable code
> will have a generic fallback for other compilers. If we level up our gcc
> version we'll get better code for free.
> > * Since GCC doesn't have an equivalent to __has_feature, C++11 code
> tends to make use of the new features based on the compiler version. GCC
> 4.2 had hardly any C++11 support at all.
> > * Things like __attribute__((deprecated("message"))) have been supported
> by clang for a long time, but portable code only enables it for GCC >= 4.5
> > * If the code isn't aware of clang we may get workarounds for compiler
> bugs that were fixed in GCC a long time ago and never existed in clang.
> >
> > Of course this doesn't come without problems.
> > * New attributes were added, I'm relatively sure we support (or at least
> silently ignore) most of them but some code may get an exploding number of
> warnings due to ignored attributes when we flip the version number.
> > * New builtins were added. This is even worse, as compiling will fail if
> such a builtin is encountered. I dug through GCC release notes from 4.3 to
> 4.7 and only found __builtin_assume_aligned and __builtin_complex (both
> added in 4.7) that are missing in clang. There may be others that weren't
> listed in the release notes.
> >
> > With that info in mind I propose changing clang's gcc version to 4.6.3
> (currently the latest in the 4.6 series) and keep on bumping it as we gain
> source-level compatibility with newer GCC versions. If you have any
> concerns about code that may break if we do that, please share so we can
> avoid problems.
> >
> > - Ben
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120512/0a981ba2/attachment.html>