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

[Chris Lattner]

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