Re: Feature request - a macro defined for GCC
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
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
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
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 x1; }
#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: basileatstarynkevitchdotnet 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
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
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
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 [EMAIL PROTECTED]
Re: Feature request - a macro defined for GCC
[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
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
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 [EMAIL PROTECTED]
Re: Feature request - a macro defined for GCC
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
Paul Koning: Ralf == Ralf Wildenhues [EMAIL PROTECTED] 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
Re: Feature request - a macro defined for GCC
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
On 2008-07-02 00:12:33 +, 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 [EMAIL PROTECTED] - 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
On Wed, Jul 02, 2008 at 03:47:49PM +0200, Vincent Lefevre wrote: On 2008-07-02 00:12:33 +, 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
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 [EMAIL PROTECTED] - 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
On Wed, Jul 2, 2008 at 5:16 PM, Vincent Lefevre [EMAIL PROTECTED] 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
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
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
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
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
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
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
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
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
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 [EMAIL PROTECTED]
Re: Feature request - a macro defined for GCC
x z [EMAIL PROTECTED] 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
On Tue, Jul 01, 2008 at 05:34:17PM +, 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
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
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
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
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
[EMAIL PROTECTED]
RE: Feature request - a macro defined for GCC
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
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
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
