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

Benjamin Kramer benny.kra at googlemail.com
Wed May 16 09:10:14 PDT 2012


On 16.05.2012, at 18:01, PaX Team wrote:

> On 16 May 2012 at 15:19, Benjamin Kramer wrote:
> 
>> 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. 
> 
> have you considered making the simulated/claimed gcc version configurable
> on the clang command line? this way distros/etc could just set it in the
> CFLAGS used for compiling glibc, so it'd be a very simple change in the
> existing build/packaging systems.

that's easy:
clang -U__GNUC_MINOR__ -D__GNUC_MINOR__=7 foo.c

However the problem is not compiling glibc. That's something completely different that won't ever work with clang unless the glibc maintainers move. It uses extensions that are broken beyond repair like __builtin_apply and -fno-toplevel-reorder, making it a lot worse to deal with than the linux kernel.

The problem is that glibc uses those extensions in the standard header files (if FORTIFY_SOURCE is specified) so any code base using e.g. stdio.h and FORTIFY_SOURCE will have to change the gcc version clang simulates, which is not acceptable.

- Ben



More information about the cfe-dev mailing list