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

[Benjamin Kramer]

On 12.05.2012, at 23:09, Chandler Carruth wrote:

> I'm looking into making this change, but there is at least one roadblock: __builtin_va_arg_pack (and _len). glibc makes quite heavy use of these in its public headers when the compiler is newer than GCC 4.3. I think we will have to add support for them in order to make this change. I'll try to look into that next....

This is also http://llvm.org/bugs/show_bug.cgi?id=7219

Sadly, this is one of the more annoying builtins :(

- Ben

> -Chandler
> 
> On Sat, May 12, 2012 at 1:43 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 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
> 
>