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.
If we want to make progress on this issue, we need to get people to
understand what the underlying problem is first, and adopt changes that
will lead to a solution, otherwise adding new macros is futile.
One thing I haven't seen you answer yet is why you think you need a
macro that uniquely identifies GCC. If the Intel compiler correctly
implements the GNU C language, then it should not matter whether the
code is being compiled by GCC or ICC. I think it would help the
discussion if you could give a specific testcase where this matters.
Jim
