[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....

Looks like we really underestimated this builtin, it's not really feasible to implement without a IRGen-level inliner. This is a huge amount of work for a little feature and I'm inclined to put it into the hall of broken gcc extensions right next to __builtin_apply.

On the attribute side there are at least 3 more attributes we'd need for glibc:

- attribute((warning("msg"))) and attribute((error("msg")). They look easy but the painful part is that they rely on CFG information so no warning/error is emitted for dead code. It's intended for use with __builtin_constant_p and inlining, something that we don't fully support either. At the moment we could get away with just using the normal mechanisms for dead-code warning suppression in clang.
- attribute((artificial)) this looks like a crude hack to suppress debug info for inline functions, I'm not sure about the implications.

So far we got away rather well with only implementing a more or less sane subset of gcc extensions even if our GNUC_MINOR suggests that we support all of them up to gcc 4.2 (including __builtin_apply and nested functions). So now thanks to the piece of software glibc is we're stuck at gcc 4.2 even though our subset of extensions expands greatly beyond that.

- 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
> 
>