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

[Chandler Carruth]

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

-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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120512/17c0b557/attachment.html>