Author: Chris Lattner Date: To: Jim Wilson CC: x z, gcc Subject: Re: Feature request - a macro defined for GCC
On Jul 3, 2008, at 9:01 AM, Jim Wilson wrote:
> x z wrote:
>>> If we want to fix this, gcc must change. And this may
>>> also require GNU libc changes and linux kernel changes, etc.
>> Maybe you can enlighten us a bit on why GNU libc and linux kernel
>> need changes so that we can realize better how complicated the
>> issue is.
>
> Because there are header files in /usr/include that test __GNUC__.
> In order for these header files to do the right thing, the Intel
> compiler (and other compilers) need to define __GNUC__.
>
> Now suppose we add a new macro __GCC_COMPILER__ that is intended to
> be unambiguous, and mean only that this is the GCC compiler. What
> happens next? Within a few months, someone will post a patch to
> glibc and/or the linux kernel that uses __GCC_COMPILER__, based on
> the misconception that because it is new, that they are supposed to
> use it. A few months later, there is a glibc release and/or linux
> kernel release that contains this code. A few months later it gets
> into a linux release. Then Intel discovers that their compiler no
> longer works as intended on linux, and in order to fix it, they have
> to define __GCC_COMPILER__. And now we are back where we started,
> except now we have two useless ambiguous macros instead of one, and
> hence we are worse off than before.
IMO, the whole notion of a compiler-specific macro has pretty limited
usefulness. Why not add macros for specific *features* offered by the
compiler. For example:
#ifdef __SUPPORTS_NESTED_FUNCTIONS__
is much better than some mismash of version checking, which isn't
guaranteed to be right in the future. One disadvantage of this is
that it will put even more burden on the already overloaded
preprocessor. It would be much nicer to have a feature query system
that doesn't rely on one macro per system. Perhaps something like:
