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

[David Chisnall]

On 16 May 2012, at 17:58, Konstantin Tokarev wrote:

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

Technically, we don't do that for 4.2 either, since we don't implement the __builtin_apply() stuff, which GCC 4.2 does (or, rather, claims to - it works in some cases on some platforms), nor do we support nested functions (unless someone added that while I was asleep).  

Perhaps I missed something, but I am not certain what the advantage of bumping the gcc version that we claim is.  We are not gcc, we are clang.  We advertise GCC 4.2 compatibility, because that makes porting code easier - anything that worked with GCC 4.2 should work with clang.  

We also provide a rich set of feature test macros that allow people to check for specific features.  By chasing a specific GCC version, we would be telling people that GCC is the standard compiler, look to it for a reference.  I don't believe this is the correct message to be sending.  The definition of __GNUC__ should be regarded as a legacy compatibility hack, not a maintained feature.

If the real problem is glibc not turning on features that we support, then the correct solution is to provide glibc with patches that use __has_feature() and friends to turn them on selectively.  An even better solution would be to engage with the GCC community and persuade them of the merits of implementing __has_feature() and __has_builtin().  A couple of codebases that I work on have started using these as the default way of testing for features - if gcc doesn't implement the test macros then they are in the exact situation that clang is in with respect to glibc: the compiler is simply assumed not to support them and we fall back to a slower code path for that compiler.

David

-- Sent from my Apple II