x z wrote:
This is somewhat off-topic. Perhaps the GCC development team should
consider making this __GNUC__ stuff more clarified in the GCC Manual.
I don't think this is off-topic. We need to get people to understand
that __GNUC__ is ambiguous before we can solve the problem. It means
two things:
1) This code is written in the GNU C language.
2) This code is meant to be compiled by GCC.
Other compilers that implement the GNU C language are forced to define
__GNUC__ because of the first issue, even though it then confuses the
second issue. If we want to fix this, gcc must change. And this may
also require GNU libc changes and linux kernel changes, etc.
The talk about whether __GNUC__ is defined by the preprocessor or the
compiler proper is irrelevant. Either way, it is still ambiguous.
You are right that we may also have trouble with other related macros.
I am not sure if there is a GNU Fortran language, if there is, then we
may have the same problem with __GFORTRAN__.
We don't need things like __GNUG_MINOR__ as G++ is always distributed in
lock step with the C compiler, so we only need one set of macros for gcc
version numbers.
We do however have the problem that the GNU C language changes
frequently, and people have gotten in the habit of testing
__GNUC_MINOR__ and other related macros to determine which features are
present in the version of the GNU C language implemented by this
compiler. Hence, this means that other compilers that implement the GNU
C language may also be forced to define macros like __GNUC_MINOR__
through no fault of their own, to correctly describe which version of
the GNU C language that they implement.
This is a very complicated issue, and until people realize how
complicated it has gotten, and accept that we need a solution, it is
unlikely that we will make progress on this issue.
Jim
