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

Konstantin Tokarev annulen at yandex.ru
Wed May 16 09:58:37 PDT 2012

16.05.2012, 17:19, "Benjamin Kramer" <benny.kra at googlemail.com>:
> 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.

I think if you claim that compiler is a drop-in replacement of certain GCC version you must support all of its intrinsics, and glibc is merely a test case.


More information about the cfe-dev mailing list