Feature request - a macro defined for GCC

Feature request - a macro defined for GCC

[x z]

I would like to see that GCC define a macro in the case it is being used to compile a program. Currently there is a __GNUC__ macro defined by the GNU C preprocessor CPP.  That does not suit the need.  As the CPP Manual says: __GNUC__ is "defined by all GNU compilers that use the C preprocessor".  It seems to imply that any (non-GNU) compiler that uses the GNU C preprocessor would also have __GNUC__ defined.  According to their respective manuals, Intel C++ Compiler and Portable C Compiler also pre-define __GNUC__, possibly because they use the GNU CPP.  Therefore, the fact that __GNUC__ is defined does not necessarily mean the GCC compiler proper is being used.  There is a need for a macro that definitely confirms that GCC is being used.  (It is another matter if another complier deliberately misleads people by defining the same macro.) And I hope that macro can be documented in the GCC Manual.

_________________________________________________________________
Need to know now? Get instant answers with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_062008

Re: Feature request - a macro defined for GCC

[Denys Vlasenko]

On Tuesday 01 July 2008 07:33, x z wrote:
> 
> I would like to see that GCC define a macro in the case it is being used to compile a program. Currently there is a __GNUC__ macro defined by the GNU C preprocessor CPP.  That does not suit the need.  As the CPP Manual says: __GNUC__ is "defined by all GNU compilers that use the C preprocessor". 

My monitor is not wide enough for your lines.

> It seems to imply that any (non-GNU) compiler that
> uses the GNU C preprocessor would also have __GNUC__ defined.

Did you test this theory?

> According to their respective manuals, Intel C++ Compiler
> and Portable C Compiler also pre-define __GNUC__, possibly
> because they use the GNU CPP.

It's their fault that they lie to the user.

> Therefore, the fact that __GNUC__ is defined does not necessarily mean the GCC compiler proper is being used.  There is a need for a macro that definitely confirms that GCC is being used.  (It is another matter if another complier deliberately misleads people by defining the same macro.) And I hope that macro can be documented in the GCC Manual.      

--
vda

Re: Feature request - a macro defined for GCC

[Denys Vlasenko]

On Tuesday 01 July 2008 07:33, x z wrote:
> 
> I would like to see that GCC define a macro in the case it is being used to compile a program. Currently there is a __GNUC__ macro defined by the GNU C preprocessor CPP.  That does not suit the need.  As the CPP Manual says: __GNUC__ is "defined by all GNU compilers that use the C preprocessor". 

My monitor is not wide enough for your lines.

> It seems to imply that any (non-GNU) compiler that
> uses the GNU C preprocessor would also have __GNUC__ defined.

Did you test this theory?

> According to their respective manuals, Intel C++ Compiler
> and Portable C Compiler also pre-define __GNUC__, possibly
> because they use the GNU CPP.

It's their fault that they lie to the user.

> Therefore, the fact that __GNUC__ is defined does not necessarily mean the GCC compiler proper is being used.  There is a need for a macro that definitely confirms that GCC is being used.  (It is another matter if another complier deliberately misleads people by defining the same macro.) And I hope that macro can be documented in the GCC Manual.      

--
vda

Re: Feature request - a macro defined for GCC

[Andrew Haley]

x z wrote:

> I would like to see that GCC define a macro in the case it is being
> used to compile a program. Currently there is a __GNUC__ macro
> defined by the GNU C preprocessor CPP.  That does not suit the need.
> As the CPP Manual says: __GNUC__ is "defined by all GNU compilers
> that use the C preprocessor".  It seems to imply that any (non-GNU)
> compiler that uses the GNU C preprocessor would also have __GNUC__
> defined.  According to their respective manuals, Intel C++ Compiler
> and Portable C Compiler also pre-define __GNUC__, possibly because
> they use the GNU CPP.

They don't use GNU CPP.

> Therefore, the fact that __GNUC__ is defined does not necessarily
> mean the GCC compiler proper is being used.

I don't think you've thought about this thoroughly.

Any compiler that is not GNU C but defines __GNUC__ is lying to its
users.  If we define __REAL_GNUC__ they'll just define that as well.

Andrew.

Re: Feature request - a macro defined for GCC

[Robert Dewar]

Andrew Haley wrote:
> x z wrote:
> 
>> I would like to see that GCC define a macro in the case it is being
>> used to compile a program. Currently there is a __GNUC__ macro
>> defined by the GNU C preprocessor CPP.  That does not suit the need.
>> As the CPP Manual says: __GNUC__ is "defined by all GNU compilers
>> that use the C preprocessor".  It seems to imply that any (non-GNU)
>> compiler that uses the GNU C preprocessor would also have __GNUC__
>> defined.  According to their respective manuals, Intel C++ Compiler
>> and Portable C Compiler also pre-define __GNUC__, possibly because
>> they use the GNU CPP.
> 
> They don't use GNU CPP.
> 
>> Therefore, the fact that __GNUC__ is defined does not necessarily
>> mean the GCC compiler proper is being used.
> 
> I don't think you've thought about this thoroughly.
> 
> Any compiler that is not GNU C but defines __GNUC__ is lying to its
> users.  If we define __REAL_GNUC__ they'll just define that as well.

Perhaps we could trademark _REAL_HONEST_GNU_CC_ and then sue anyone
who used the trademark (since this would pretty clearly be a case
of trademark dilution I would think!) After all you can't put GUCCI
on your knock off shoe designs :-)
> 
> Andrew.

Re: Feature request - a macro defined for GCC

[rkiesling]

Robert Dewar:
[ Charset ISO-8859-1 converted... ]
> Andrew Haley wrote:
> > x z wrote:
> > 
> >> I would like to see that GCC define a macro in the case it is being
> >> used to compile a program. Currently there is a __GNUC__ macro
> >> defined by the GNU C preprocessor CPP.  That does not suit the need.
> >> As the CPP Manual says: __GNUC__ is "defined by all GNU compilers
> >> that use the C preprocessor".  It seems to imply that any (non-GNU)
> >> compiler that uses the GNU C preprocessor would also have __GNUC__
> >> defined.  According to their respective manuals, Intel C++ Compiler
> >> and Portable C Compiler also pre-define __GNUC__, possibly because
> >> they use the GNU CPP.
> > 
> > They don't use GNU CPP.
> > 
> >> Therefore, the fact that __GNUC__ is defined does not necessarily
> >> mean the GCC compiler proper is being used.
> > 
> > I don't think you've thought about this thoroughly.
> > 
> > Any compiler that is not GNU C but defines __GNUC__ is lying to its
> > users.  If we define __REAL_GNUC__ they'll just define that as well.

I guess the last reply didn't make it to the list.  The include files
need __GNUC__ and other builtin macros to include type definitions.
The builtin macros aren't needed by the compiler proper, and adding
another builtin wouldn't help in special cases.  For example, the
GNU configurations occationionally need to use -DWITH_GCC or something
similar.  

I didn't know that anyone had a special claim to GNU and/or GCC.  I
thought the trademark thing was tried, but, with all of the instances
of GCC already on bookshelves, for example, it didn't seem very
successful.  But, IANTL, of course.

--
Add this signature to your message and contribute to world nomidation.

Re: Feature request - a macro defined for GCC

[Robert Dewar]

rkiesling wrote:

> I didn't know that anyone had a special claim to GNU and/or GCC. 

The free software foundation owns the copyright, or has assignments
of the copyrights from authors, so it indeed has a "special claim".

> I
> thought the trademark thing was tried, but, with all of the instances
> of GCC already on bookshelves, for example, it didn't seem very
> successful.  But, IANTL, of course.

Yes, well trademarking GCC at this stage might be tricky, which is
why I suggested a more distinctive string :-)
> 
> --
> Add this signature to your message and contribute to world nomidation.

Re: Feature request - a macro defined for GCC

[x z]

I think an important point was missed in the discussion.  Some seem to focus on the dishonest definition of __GNUC__ by non-GNU C compilers.  That was not my point.  My point is that if __GNUC__ is defined by CPP, not the GNU C compiler proper, (and this seems to be supported by the CPP Manual,) and any (non-GNU) C compiler can use CPP, then those non-GNU C compilers would "inadverdently" define __GNUC__ and lead people to believe that they are GNU C.  That is why I think the GNU C compiler should define a macro independently from CPP.  Or, alternatively, __GNUC__ should be defined by the GCC compiler proper, not CPP.
_________________________________________________________________
The i’m Talkaton. Can 30-days of conversation change the world?
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_ChangeWorld

Re: Feature request - a macro defined for GCC

[Andrew Haley]

x z wrote:

> I think an important point was missed in the discussion.  Some seem
> to focus on the dishonest definition of __GNUC__ by non-GNU C
> compilers.  That was not my point.  My point is that if __GNUC__ is
> defined by CPP, not the GNU C compiler proper, (and this seems to be
> supported by the CPP Manual,) and any (non-GNU) C compiler can use
> CPP, then those non-GNU C compilers would "inadverdently" define
> __GNUC__ and lead people to believe that they are GNU C.

Does any non-GNU C compiler use GNU CPP?  No.

> That is why I think the GNU C compiler should define a macro
> independently from CPP.  Or, alternatively, __GNUC__ should be
> defined by the GCC compiler proper, not CPP.

And how can any part of the compiler other than the preprocessor
define a macro?  Macros do not exist outside the preprocessor.

Andrew.

Re: Feature request - a macro defined for GCC

[Peter Barada]

> I think an important point was missed in the discussion.  Some seem to
> focus on the dishonest definition of __GNUC__ by non-GNU C compilers.
> That was not my point.  My point is that if __GNUC__ is defined by
> CPP, not the GNU C compiler proper, (and this seems to be supported by
> the CPP Manual,) and any (non-GNU) C compiler can use CPP, then those
> non-GNU C compilers would "inadverdently" define __GNUC__ and lead
> people to believe that they are GNU C.  That is why I think the GNU C
> compiler should define a macro independently from CPP.  Or,
> alternatively, __GNUC__ should be defined by the GCC compiler proper,
> not CPP. 

And do what with the preprocessor symbol?  If the symbol is defined by
the compiler *after* preprocessing occurs(as in the compiler and not
the preprocessor) , then it can't be used to selectively preprocess code...

-- 
Peter Barada
peter@the-baradas.com

Re: Feature request - a macro defined for GCC

[Ian Lance Taylor]

x z <hzmonte@hotmail.com> writes:

> I think an important point was missed in the discussion.  Some seem
> to focus on the dishonest definition of __GNUC__ by non-GNU C
> compilers.  That was not my point.  My point is that if __GNUC__ is
> defined by CPP, not the GNU C compiler proper, (and this seems to be
> supported by the CPP Manual,) and any (non-GNU) C compiler can use
> CPP, then those non-GNU C compilers would "inadverdently" define
> __GNUC__ and lead people to believe that they are GNU C.  That is
> why I think the GNU C compiler should define a macro independently
> from CPP.  Or, alternatively, __GNUC__ should be defined by the GCC
> compiler proper, not CPP.

I very much doubt that any compiler other than gcc uses the gcc
preprocessor.

In any case, the documentation has in some sense misled you.  __GNUC__
is indeed defined by the compiler proper, not by the preprocessor.
But that in turn does not matter, as if any non-gcc compiler *did* use
the gcc preprocessor, it would do so via gcc -E.  In gcc, the
preprocessor is not a separate program.  Using gcc -E would define
__GNUC__ as indeed it should.  So there is really no escape.

One can only hope that, in the unlikely event that some other compiler
uses the gcc preprocessor, it passes the -undef option to turn off the
macros defined by the compiler proper.

Ian

Re: Feature request - a macro defined for GCC

[Jack Lloyd]

On Tue, Jul 01, 2008 at 05:34:17PM +0000, x z wrote:
> 
> I think an important point was missed in the discussion.  Some seem to focus on the dishonest definition of __GNUC__ by non-GNU C compilers.  That was not my point.  My point is that if __GNUC__ is defined by CPP, not the GNU C compiler proper, (and this seems to be supported by the CPP Manual,) and any (non-GNU) C compiler can use CPP, then those non-GNU C compilers would "inadverdently" define __GNUC__ and lead people to believe that they are GNU C.  That is why I think the GNU C compiler should define a macro independently from CPP.  Or, alternatively, __GNUC__ should be defined by the GCC compiler proper, not CPP.

Perhaps you can use 'defined(__GNUC__) && !defined(__INTEL_COMPILER)'

In www.intel.com/cd/software/products/asmo-na/eng/284736.htm (warning: a PDF, despite
the .htm extension (!)):

"A new option has been added, -gcc-sys, which is similar to -no-gcc,
except that the GNU macros are only defined when preprocessing system
include headers files, so these will compile correctly."

Googling "Intel C++ __GNUC__" shows several major projects have been
affected by this icc misfeature.

-Jack

RE: Feature request - a macro defined for GCC

[x z]

> I very much doubt that any compiler other than gcc uses the gcc
> preprocessor.
>
> In any case, the documentation has in some sense misled you. __GNUC__
> is indeed defined by the compiler proper, not by the preprocessor.
> But that in turn does not matter, as if any non-gcc compiler *did* use
> the gcc preprocessor, it would do so via gcc -E. In gcc, the
> preprocessor is not a separate program.

Just one piece of info: A mpC compiler for parallel language uses GNU CPP: "The mpC compiler uses standard preprocessor cpp. You should specify the directory where cpp is placed when editing Makefile. We recommend to use GNU cpp."  (http://www.ispras.ru/~mpc/mpc-122-iguide.html).  I know, mpC is not exactly a C compiler.  But it seems that it is feasible (and was done) to use GNU CPP as a preprocesser in a compiler for C or a language based on C.

_________________________________________________________________
Need to know now? Get instant answers with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_messenger_072008

RE: Feature request - a macro defined for GCC

[x z]

> In any case, the documentation has in some sense misled you. __GNUC__
> is indeed defined by the compiler proper, not by the preprocessor.
> But that in turn does not matter, as if any non-gcc compiler *did* use
> the gcc preprocessor, it would do so via gcc -E. 

> Googling "Intel C++ __GNUC__" shows several major projects have been
> affected by this icc misfeature.

Upon further checking the GNU CPP Manual, some interesting things are revealed.
The current manual (http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros) (version unspecified) says: 
__GNUC__
__GNUC_MINOR__
__GNUC_PATCHLEVEL__
These macros are defined by all GNU compilers that use the C preprocessor: C, C++, Objective-C and Fortran. ... These macros are also defined if you invoke the preprocessor directly.  ... If all you need to know is whether or not your program is being compiled by GCC, or a non-GCC compiler that claims to accept the GNU C dialects, you can simply test __GNUC__. 
Therefore, Intel C++ Compiler's definition of __GNUC__ appears to be legitimate if Intel honestly makes a reasonable claim that its compiler accepts the GNU C dialects.
In comparison, the GNU CPP 2.8.1 (1997) Manual (http://sunsite.ualberta.ca/Documentation/Gnu/gcc-2.8.1/html_node/cpp_13.html#SEC14)  says:
__GNUC__ 
This macro is defined if and only if this is GNU C. This macro is defined only when the entire GNU C compiler is in use; if you invoke the preprocessor directly, `__GNUC__' is undefined. 
It seems this 1997 definition is more strict: a non-GCC compiler should never define __GNUC__.  In other words, in 1997, __GNUC__ can be used to uniquely identify the GNU C compiler, now it can't; and nothing can.  
On the other hand, the 1997 sentence "if you invoke the preprocessor directly, `__GNUC__' is undefined" is now replaced by "These macros are also defined if you invoke the preprocessor directly."  I have not had the time to find out what "invoke the preprocessor directly" means ('gcc -E' ?) but now the implication is that a non-'GNU C'-compliant compiler that uses GNU CPP as its preprocessor would have __GNUC__ defined, unless it takes the extra effort to somehow undefine it.
And this also raises an interesting question: "These macros are also defined if you invoke the preprocessor directly" seems to imply that __GNUC__ is defined by the preprocessor, not the compiler proper.  This appears to contradict the claim in a previous post (see above quote) that "__GNUC__ is indeed defined by the compiler proper, not by the preprocessor."
_________________________________________________________________
It’s a talkathon – but it’s not just talk.
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_JustTalk

Re: Feature request - a macro defined for GCC

[Jim Wilson]

x z wrote:
> I would like to see that GCC define a macro in the case it is being used to compile a program. Currently there is a __GNUC__ macro defined by the GNU C preprocessor CPP.

This is our mistake.  Originally __GNUC__ meant that this was the GNU C 
compiler (aka GNU Compiler Collection).  However, we have added so many 
extensions to the compiler that it later came to mean that this is the 
GNU C language.  There is unfortunately no way to distinguish between a 
program written in GNU C, and a program intended to be compiled by the 
GNU C compiler.  All compilers that implement the GNU C language must 
define __GNUC__.  There is no way around this.  The use of __GNUC__ is 
so pervasive in GNU/Linux that a compiler has to define it or else it 
simply won't work.  This is why the Intel compilers and other compilers 
define it.  They have no choice.

If we want a solution to this problem, complaining to Intel and others 
will do no good.  We will have to fix it ourselves.  One way to fix the 
problem is to separate the meaning of the macros.  We can have one macro 
that means "this is a GNU C program" and other macro that means "this is 
the GNU C compiler".  We then have to make sure that glibc and other 
libraries use the macros correctly.  Etc.

While I agree that this is our mistake, it isn't clear to me why it 
matters.  If the Intel compiler correctly implements the GNU C language, 
then it shouldn't matter if the code is being compiled by GCC or ICC. 
Unless maybe you ran into a GCC bug, and want to enable a workaround 
only for GCC.

Jim

RE: Feature request - a macro defined for GCC

[Joseph S. Myers]

On Tue, 1 Jul 2008, x z wrote:

> On the other hand, the 1997 sentence "if you invoke the preprocessor 
> directly, `__GNUC__' is undefined" is now replaced by "These macros are 
> also defined if you invoke the preprocessor directly."  I have not had 
> the time to find out what "invoke the preprocessor directly" means ('gcc 
> -E' ?) but now the implication is that a non-'GNU C'-compliant compiler 
> that uses GNU CPP as its preprocessor would have __GNUC__ defined, 
> unless it takes the extra effort to somehow undefine it.

In the 2.8.1 manual, it meant invoking the file 
lib/gcc-lib/$target/2.8.1/cpp, an internal binary not installed in any 
user binary directory that was called internally by the compiler binary 
"gcc" (along with other binaries such as "cc1").

This internal binary no longer exists.  Instead, there is a "cpp" binary 
installed in the user binary directory, which calls the "cc1" binary to do 
the same preprocessing as it does when compiling; that is, it has the same 
effect as "gcc -E".  The better consistency in predefined macros is 
deliberate.

-- 
Joseph S. Myers
joseph@codesourcery.com

RE: Feature request - a macro defined for GCC

[x z]

This is somewhat off-topic.  Perhaps the GCC development team should
consider making this __GNUC__ stuff more clarified in the GCC Manual.
Now, this __GNUC__ stuff appears to appear only in the CPP Manual
(section 3.7.2).  And the definition of similar macros such as __GFORTRAN__
and __GNUG__ may need to be further explained in this vein.  Currently, 
__GFORTRAN__ means "The GNU Fortran compiler defines this."  Should it 
rather mean "This is a GNU Fortran-complaint compiler", to be consistent
with the meaning of __GNUC__?  And, for example, should there be 
__GNUG_MINOR__ and __GNUG_PATCHLEVEL__ too?
Interestingly, there is a __VERSION__ macro ("which describes the version 
of the compiler in use").  There is some discussion in this thread on whether  
these macros are defined in the preprocessor or the compiler proper.  If 
these macros are processed by the preprocessor, and the C, C++, Fortran,
etc compilers all share CPP, then how would the preprocessor report the
correct version of the compiler in use?  It somehow checks with the
compiler to see whether it is C or Fortran, and then report the appropriate
version of the compiler?  

_________________________________________________________________
It’s a talkathon – but it’s not just talk.
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_JustTalk

Re: Feature request - a macro defined for GCC

[Jim Wilson]

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

RE: Feature request - a macro defined for GCC

[x z]

> 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.

> The talk about whether __GNUC__ is defined by the preprocessor or the
> compiler proper is irrelevant. Either way, it is still ambiguous.
IMHO, it is irrelevant as far as whether __GNUC__ is ambiguous.  However,
I think it is relevant as far as how it can be fixed, if at all.  So, if you
have some insight as to whether __GNUC__ is defined by the preprocessor 
or the compiler proper, please let us know.  It does not hurt anyway.

> 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__.
There is a GNU Fortran compiler for sure.  So, just as people consider
the syntax and semantics of a language accepted by the GNU C compiler
as sort of a C language specification (i.e. whatever accepted by GNU C
compiler 4.3.1 becomes GNU C Standard 4.3.1), there is a GNU Fortran
language.  Whatever accepted by the GNU Fortran compiler becomes
the GNU Fortran language spec. 

> 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.
Then maybe __GNUFORTRAN_MINOR__ .

Anyway, assumed GNU Fortran and GNU C are not distributed in lock step, then
the __VERSION__ macro should be clarified as to whether it refers to the
C or Fortran version (or the version of CPP itself - well, I guess CPP is also
distributed with C in lock step so they share the same version).
_________________________________________________________________
Need to know now? Get instant answers with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_messenger_072008

Re: Feature request - a macro defined for GCC

[Andrew Haley]

Jim Wilson wrote:
> If the Intel compiler correctly implements the GNU C language,
> then it shouldn't matter if the code is being compiled by GCC or ICC.
> Unless maybe you ran into a GCC bug, and want to enable a workaround
> only for GCC.

I think you'd want to conditionalize such a test on the GCC version
anyway.

Andrew.

Re: Feature request - a macro defined for GCC

[Vincent Lefevre]

On 2008-07-01 11:11:42 -0700, Ian Lance Taylor wrote:
> __GNUC__ is indeed defined by the compiler proper, not by the
> preprocessor.

What do you mean here?

Even when calling the preprocessor directly, __GNUC__ is defined:

vin% gcc -dM -E -xc /dev/null | grep __GNUC__
#define __GNUC__ 4
vin% cpp -dM /dev/null | grep __GNUC__
#define __GNUC__ 4

> But that in turn does not matter, as if any non-gcc compiler *did* use
> the gcc preprocessor, it would do so via gcc -E.  In gcc, the
> preprocessor is not a separate program.

But in any case, there's a separate preprocessor: cpp. And perhaps cpp
shouldn't define __GNUC__.

(BTW, this isn't a compiler, but xrdb uses cpp by default.)

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Feature request - a macro defined for GCC

[Vincent Lefevre]

On 2008-07-02 00:12:33 +0000, Joseph S. Myers wrote:
> This internal binary no longer exists. Instead, there is a "cpp"
> binary installed in the user binary directory, which calls the "cc1"
> binary to do the same preprocessing as it does when compiling; that
> is, it has the same effect as "gcc -E".

Not exactly:

vin% cpp -dM /dev/null | wc -l
128
vin% gcc -E -dM /dev/null | wc -l
gcc.real: /dev/null: linker input file unused because linking not done
0

Is it a bug of "gcc -E"?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Feature request - a macro defined for GCC

[Jack Lloyd]

On Wed, Jul 02, 2008 at 03:47:49PM +0200, Vincent Lefevre wrote:
> On 2008-07-02 00:12:33 +0000, Joseph S. Myers wrote:
> > This internal binary no longer exists. Instead, there is a "cpp"
> > binary installed in the user binary directory, which calls the "cc1"
> > binary to do the same preprocessing as it does when compiling; that
> > is, it has the same effect as "gcc -E".
> 
> Not exactly:
> 
> vin% cpp -dM /dev/null | wc -l
> 128
> vin% gcc -E -dM /dev/null | wc -l
> gcc.real: /dev/null: linker input file unused because linking not done
> 0
> 
> Is it a bug of "gcc -E"?

Not really, it just doesn't understand it needs to treat an empty file as
C... instead you have to tell it so with -x c

(wks9 ~)$ cpp -dM /dev/null | wc -l
86
(wks9 ~)$ gcc -E -dM /dev/null | wc -l
gcc: /dev/null: linker input file unused because linking not done
0
(wks9 ~)$ gcc -E -x c -dM /dev/null | wc -l
86
(wks9 ~)$ gcc -E -x c++ -dM /dev/null | wc -l
92

Re: Feature request - a macro defined for GCC

[Andreas Schwab]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

> On 2008-07-02 00:12:33 +0000, Joseph S. Myers wrote:
>> This internal binary no longer exists. Instead, there is a "cpp"
>> binary installed in the user binary directory, which calls the "cc1"
>> binary to do the same preprocessing as it does when compiling; that
>> is, it has the same effect as "gcc -E".
>
> Not exactly:
>
> vin% cpp -dM /dev/null | wc -l
> 128
> vin% gcc -E -dM /dev/null | wc -l
> gcc.real: /dev/null: linker input file unused because linking not done
> 0
>
> Is it a bug of "gcc -E"?

You need to tell gcc that /dev/null is a C file, since it does not have
a recognized extension.

$ gcc -E -dM -xc /dev/null | wc -l
120

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Feature request - a macro defined for GCC

[Ian Lance Taylor]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

>> But that in turn does not matter, as if any non-gcc compiler *did* use
>> the gcc preprocessor, it would do so via gcc -E.  In gcc, the
>> preprocessor is not a separate program.
>
> But in any case, there's a separate preprocessor: cpp. And perhaps cpp
> shouldn't define __GNUC__.

You're right, there is a program which appears to be a separate
preprocessor.  In actual fact, that program is just gcc under a
different name.

I think it would be reasonable to argue that that program should not
define __GNUC__ by default.  I don't actually know which choice people
would find more surprising.  And unfortunately I also don't know how
to find out.

Ian

Re: Feature request - a macro defined for GCC

[Vincent Lefevre]

On 2008-07-02 10:10:32 -0400, Jack Lloyd wrote:
> Not really, it just doesn't understand it needs to treat an empty
> file as C... instead you have to tell it so with -x c

But is there any reason why cpp assumes C as a fallback, but not gcc
(at least with the -E option)? IMHO, this is a bit inconsistent, in
particular if cpp is seen as a synonym for "gcc -E".

vin% cpp -dM /dev/null | md5sum
d7760eedc87eba1427f096989c3e2a49  -
vin% cpp -xc -dM /dev/null | md5sum
d7760eedc87eba1427f096989c3e2a49  -
vin% cpp -xc++ -dM /dev/null | md5sum
0ce80933d788e730beec1886af757d44  -
vin% gcc -E -dM /dev/null | md5sum   
gcc.real: /dev/null: linker input file unused because linking not done
d41d8cd98f00b204e9800998ecf8427e  -
vin% gcc -E -xc -dM /dev/null | md5sum
d7760eedc87eba1427f096989c3e2a49  -
vin% gcc -E -xc++ -dM /dev/null | md5sum
0ce80933d788e730beec1886af757d44  -

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Feature request - a macro defined for GCC

[Richard Guenther]

On Wed, Jul 2, 2008 at 5:16 PM, Vincent Lefevre <vincent+gcc@vinc17.org> wrote:
> On 2008-07-02 10:10:32 -0400, Jack Lloyd wrote:
>> Not really, it just doesn't understand it needs to treat an empty
>> file as C... instead you have to tell it so with -x c
>
> But is there any reason why cpp assumes C as a fallback, but not gcc
> (at least with the -E option)? IMHO, this is a bit inconsistent, in
> particular if cpp is seen as a synonym for "gcc -E".

Because it's Cpp, the C preprocessor.

Richard.

Re: Feature request - a macro defined for GCC

[rkiesling]

Vincent Lefevre:
[ Charset ISO-8859-1 converted... ]
> On 2008-07-01 11:11:42 -0700, Ian Lance Taylor wrote:
> > __GNUC__ is indeed defined by the compiler proper, not by the
> > preprocessor.
> 
> What do you mean here?
> 
> Even when calling the preprocessor directly, __GNUC__ is defined:
> 
> vin% gcc -dM -E -xc /dev/null | grep __GNUC__
> #define __GNUC__ 4
> vin% cpp -dM /dev/null | grep __GNUC__
> #define __GNUC__ 4
> 
> > But that in turn does not matter, as if any non-gcc compiler *did* use
> > the gcc preprocessor, it would do so via gcc -E.  In gcc, the
> > preprocessor is not a separate program.
> 
> But in any case, there's a separate preprocessor: cpp. And perhaps cpp
> shouldn't define __GNUC__.
> 
> (BTW, this isn't a compiler, but xrdb uses cpp by default.)

Try:

$ echo ' ' | cpp -undef -dM -

and determine if there's any output (varies by platform).

The ctpp preprocessor undefines all builtins when -undef is present.  See the 
URL below (plug, I know).

-- 
Ctalk Home Page: http://www.ctalklang.org

Re: Feature request - a macro defined for GCC

[Chris Lattner]

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:

#if __feature_supported(nested_functions) &&  
__feature_supported(transparent_union) &&  
__feature_supported(attribute_aligned)
...

Taking an approach reduces startup time of the preprocessor, because  
it doesn't have to populate the identifier table with tons of  
predefines.

-Chris

Re: Feature request - a macro defined for GCC

[Jim Wilson]

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

Re: Feature request - a macro defined for GCC

[Andrew Haley]

Chris Lattner wrote:

> 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.

Yeah, but in the absence of an external specification of the syntax it'd
have to be __SUPPORTS_GNU_NESTED_FUNCTIONS__.  Hmm, looks like this could
get very messy, very quickly; I don't think you could do this in any
effective way without some compiler-independent organization to define
these macros.

Andrew.

Re: Feature request - a macro defined for GCC

[Chris Lattner]

On Jul 3, 2008, at 10:01 AM, Andrew Haley wrote:

> Chris Lattner wrote:
>
>> 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.
>
> Yeah, but in the absence of an external specification of the syntax  
> it'd
> have to be __SUPPORTS_GNU_NESTED_FUNCTIONS__.

The feature names should be independent of the set of compilers that  
happen to implement them, that's the whole point.  Consider:

#ifdef __SUPPORTS_GNU_CXX_MIN_MAX_OPERATORS__

Mainline GCC doesn't support "GNU" min max operators!   GCC adds and  
removes extensions, and other compilers have good support for subsets  
of the GCC extensions.  Obviously if Intel is defining __GNUC__ with  
moderate success, then they implement whatever extensions the macro is  
guarding.

> Hmm, looks like this could
> get very messy, very quickly; I don't think you could do this in any
> effective way without some compiler-independent organization to define
> these macros.

Huh?  Why not?

-Chris

Re: Feature request - a macro defined for GCC

[Basile STARYNKEVITCH]

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. 


I fully agree with the argument, but I'll add a caveat.

The __GNUC__ macro serves two different purposes:

1. permitting the extremely useful GCC languages extensions which, for 
sad and various reasons, did not enter any official C standard (in 
particular, computed gotos, statement exprs, typeof....). We might add 
the extended asm instruction here also. I guess it is the most common 
use of __GNUC__.

2. selecting one way of expressing (in perfectly usual C code) instead 
of another which fits well with the GCC compiler in particular. I've got 
no concrete example, but I could imagine some code like

#ifdef __GNUC__
int twice(int x) { return x*2; }
#else
int twice(int x) { return x<<1; }
#endif

Of course, the above example is very stupid, but I hope you get my 
point. I expect this kind of use to be very rare.

And I agree that the separation is a bit fuzzy. Some people could argue 
that some __builtin fits in between the two points.

Maybe we should separate the two roles above, and most importantly 
*document* them, We might perhaps:

leave the __GNUC__ macro for the first role (GCC language extensions), 
and perhaps define a __GCC_COMPILER__ macro for the second role, by 
documenting it appropriately, and prohibiting any way of defining it 
[except by patching the source code of GCC].

Regards.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Feature request - a macro defined for GCC

[Ralf Wildenhues]

Hello,

>> Chris Lattner wrote:
>>
>>> 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__
[...]
>> Hmm, looks like this could
>> get very messy, very quickly; I don't think you could do this in any
>> effective way without some compiler-independent organization to define
>> these macros.

I feel like I'm stating the obvious, but maybe you're just trying to
rediscover feature-based tests: do a test compile that exposes the
compiler bug or feature you're looking for.

Autoconf provides a framework that supports this kind of testing, among
others.

Cheers,
Ralf

Re: Feature request - a macro defined for GCC

[Paul Koning]

>>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

 Ralf> I feel like I'm stating the obvious, but maybe you're just
 Ralf> trying to rediscover feature-based tests: do a test compile
 Ralf> that exposes the compiler bug or feature you're looking for.

 Ralf> Autoconf provides a framework that supports this kind of
 Ralf> testing, among others.

Autoconf is a massively cryptic and complicated way to make up for the
lack of "I have feature X" CPP flags in the compiler.

Chris is right, that's the correct way to do things.

      paul

Re: Feature request - a macro defined for GCC

[Chris Lattner]

On Jul 3, 2008, at 10:50 AM, Ralf Wildenhues wrote:

> Hello,
>
>>> Chris Lattner wrote:
>>>
>>>> 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__
> [...]
>>> Hmm, looks like this could
>>> get very messy, very quickly; I don't think you could do this in any
>>> effective way without some compiler-independent organization to  
>>> define
>>> these macros.
>
> I feel like I'm stating the obvious, but maybe you're just trying to
> rediscover feature-based tests: do a test compile that exposes the
> compiler bug or feature you're looking for.
>
> Autoconf provides a framework that supports this kind of testing,  
> among
> others.

That doesn't work for system headers.

-Chris

Re: Feature request - a macro defined for GCC

[Joseph S. Myers]

On Thu, 3 Jul 2008, Basile STARYNKEVITCH wrote:

> The __GNUC__ macro serves two different purposes:
> 
> 1. permitting the extremely useful GCC languages extensions which, for sad and
> various reasons, did not enter any official C standard (in particular,
> computed gotos, statement exprs, typeof....). We might add the extended asm
> instruction here also. I guess it is the most common use of __GNUC__.

Note that the view was expressed at the London WG14 meeting (going through 
a list of extensions considering what might be worth putting in C1x) that 
statement expressions and typeof might be worth standardising.  This does 
not of course mean that anyone will produce a concrete proposal to add 
appropriate words to the standard, or that such a proposal will be 
accepted for C1x.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Feature request - a macro defined for GCC

[Josh Triplett]

[Adding the Sparse mailing list to CC.]

On Thu, 2008-07-03 at 09:37 -0700, Chris Lattner wrote:
> 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:
> 
> #if __feature_supported(nested_functions) &&  
> __feature_supported(transparent_union) &&  
> __feature_supported(attribute_aligned)
> ...
> 
> Taking an approach reduces startup time of the preprocessor, because  
> it doesn't have to populate the identifier table with tons of  
> predefines.

Speaking as the maintainer of Sparse, I would love to see GCC adopt
such an approach.  I don't like that Sparse currently has to define GNUC
and other such macros, and impersonate a GCC version that implies
support for the GCC extensions it has.  While that support probably
needs to stick around for backward compatibility, I'd much rather have
Sparse support some new feature-testing construct.

I'd suggest defining exactly one new preprocessor symbol, to advertise
the support for the feature-testing mechanism.  For instance,
__HAVE_EXTENSION_SUPPORTED__, or __FEATURE_SUPPORTED_SUPPORTED__. :)
The rest could use syntax like you suggest above.  For instance:

#ifdef __HAVE_EXTENSION_SUPPORTED__
#if __have_extension__(noreturn)
#define ATTR_NORETURN __extension__((noreturn))
#endif
#if __have_extension__(sentinel)
#define ATTR_SENTINEL __extension__((sentinel))
#endif
#endif
#ifndef ATTR_NORETURN
#define ATTR_NORETURN
#endif
#ifndef ATTR_SENTINEL
#define ATTR_SENTINEL
#endif

The same thing would work for Sparse extensions:

#ifdef __HAVE_EXTENSION_SUPPORTED__
#if __have_extension__(address_space) && __have_extension__(noderef)
#define __user __extension__((address_space(1),noderef))
#endif
#endif
#ifndef __user
#define __user
#endif

The only problem then becomes maintaining the canonical list of
extension names.  We could use the ugly approach of names like
"org.gnu.gcc.extension.sentinel" and "org.kernel.sparse.address_space",
but that seems entirely too ugly.  The other alternative seems like a
central registry of extension names; I'd happily help maintain such a
registry.

Thoughts?

- Josh Triplett

Re: Feature request - a macro defined for GCC

[Chris Lattner]

On Jul 3, 2008, at 2:12 PM, Josh Triplett wrote:
> I'd suggest defining exactly one new preprocessor symbol, to advertise
> the support for the feature-testing mechanism.  For instance,
> __HAVE_EXTENSION_SUPPORTED__, or __FEATURE_SUPPORTED_SUPPORTED__. :)
> The rest could use syntax like you suggest above.  For instance:


Sure.  The idea was that you'd do something like:

#ifndef __FEATURE_SUPPORTED_SUPPORTED__  /* or whatever :) */
#define has_extension(x) 0
#else
#define has_extension(x) __has_extension__(x)
#endif

which allows you to use "#if has_extension(typeof)" in your code  
portably.

In fact, it would be easy to make __has_extension__ actually be a  
macro itself, allowing one to say:

#ifdef __has_extension__
...

which is even more clear.

> The only problem then becomes maintaining the canonical list of
> extension names.  We could use the ugly approach of names like
> "org.gnu.gcc.extension.sentinel" and  
> "org.kernel.sparse.address_space",
> but that seems entirely too ugly.  The other alternative seems like a
> central registry of extension names; I'd happily help maintain such a
> registry.

I have no opinion on an approach, but I agree that it would be good to  
have a centralized list.  I would definitely add support for this to  
Clang.

-Chris

Re: Feature request - a macro defined for GCC

[Joseph S. Myers]

On Thu, 3 Jul 2008, Chris Lattner wrote:

> 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:
> 
> #if __feature_supported(nested_functions) &&
> __feature_supported(transparent_union) &&
> __feature_supported(attribute_aligned)
> ...

This looks rather like a reinvention of the #assert system (which is 
deprecated, or at least recommended against in the manual).

> Taking an approach reduces startup time of the preprocessor, because it
> doesn't have to populate the identifier table with tons of predefines.

I'd hope this is not a significant cost (certainly not compared to the 
thousands of built-in functions on some target), though I haven't seen 
recent figures for startup costs.

We have some existing practice for feature macros (__GNUC_GNU_INLINE__, 
__GNUC_STDC_INLINE__, __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1, ...).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Feature request - a macro defined for GCC

[Chris Lattner]

On Jul 3, 2008, at 3:01 PM, Joseph S. Myers wrote:
>> Taking an approach reduces startup time of the preprocessor,  
>> because it
>> doesn't have to populate the identifier table with tons of  
>> predefines.
>
> I'd hope this is not a significant cost (certainly not compared to the
> thousands of built-in functions on some target), though I haven't seen
> recent figures for startup costs.

I was referring to clang startup times, not GCC.  clang registers  
builtins completely lazily, so they don't take significant time at  
startup.  Much of clang startup time is populating the predefined  
identifier table for macros.

> We have some existing practice for feature macros  
> (__GNUC_GNU_INLINE__,
> __GNUC_STDC_INLINE__, __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1, ...).

Understood.  Likewise many system headers have these.  I don't think  
we can eliminate existing macros, but adding a plethora of new macros  
would be bad.

-Chris

Re: Feature request - a macro defined for GCC

[rkiesling]

Paul Koning:
> >>>>> "Ralf" == Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> 
>  Ralf> I feel like I'm stating the obvious, but maybe you're just
>  Ralf> trying to rediscover feature-based tests: do a test compile
>  Ralf> that exposes the compiler bug or feature you're looking for.
> 
>  Ralf> Autoconf provides a framework that supports this kind of
>  Ralf> testing, among others.
> 
> Autoconf is a massively cryptic and complicated way to make up for the
> lack of "I have feature X" CPP flags in the compiler.
> 
> Chris is right, that's the correct way to do things.
> 
>       paul

Cpp does not, however, define macros based on command line options,
for example __C99_STD_CMD_LINE_OPTION__.  You could do the same thing
yourself with a -D__MY_C99_STUFF__, for example, on the command line.

I also feel like I keep stating the obvious, but there are a lot of
GNU C platforms that don't use glibc and wouldn't have any need for
such feature-based macros, (or they would need their own unique
features) but they still comply with standard C.

-- 
Ctalk Home Page: http://www.ctalklang.org