Re: Dealing with compilers that pretend to be GCC
Hi, Chris Lattner clatt...@apple.com skribis: On Jan 31, 2012, at 5:15 AM, Ludovic Courtès wrote: Interestingly enough: $ cat q.c __has_builtin $ clang -E q.c segfault Yes, that’s what I was asking. It makes me think that the old CPP predicates (info (gcc) Obsolete Features) would be more appropriate than compiler magic, with the caveat that they’re presumably not widely supported. They are similar in spirit. The major difference between the two is that it is easy for __has_feature and friends gracefully degrade when a compiler doesn't support them, because you can do: #ifndef __has_builtin #define __has_builtin(x) 0 #endif in your code, but you can't do anything like this for #assertion. That and assertions don't have any coverage over the features that you're interested in, and the grammar doesn't have a good way to handle multiple cases like features/attributes/extensions/etc. Rather than assertions, one could use predicates: #if #has_builtin(foo) #has_attribute(bar) ... #endif The difference being that (1) predicates were designed specifically for this purpose, and (2) there’s no magic involved. Thanks, Ludo’.
Re: Dealing with compilers that pretend to be GCC
ludovic.cour...@inria.fr (Ludovic Courtès) writes: Rather than assertions, one could use predicates: #if #has_builtin(foo) #has_attribute(bar) ... #endif The difference being that (1) predicates were designed specifically for this purpose, and (2) there’s no magic involved. but ... predicates are (1) less portable, since they involve magic syntax (whereas it's obvious how to make magic macros portable) and (2) deprecated even in gcc... -miles -- You can hack anything you want, with TECO and DDT.
Re: Dealing with compilers that pretend to be GCC
Hi, Chris Lattner clatt...@apple.com skribis: On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote: Hello, Chris Lattner clatt...@apple.com skribis: On Jan 20, 2012, at 5:24 PM, Jonathan Wakely jwakely@gmail.com wrote: On 21 January 2012 00:32, Vincent Lefevre wrote: On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: May I politely suggest that this is the wrong place to complain about other compilers pretending to be GCC :) I think that's the fault of GCC, which should have defined a macro for each extension. And what about the fact other compilers haven't defined such a macro for each extension they implement, whether it comes from GCC or not, is that GCC's fault too? If fact, some do: http://clang.llvm.org/docs/LanguageExtensions.html#feature_check That seems like a very useful approach to solve the problem. The docs say that ‘__has_builtin’ co. are macros. What do they expand to? 0 or 1. I understand. To put it another way, how are they defined? Thanks, Ludo’.
Re: Dealing with compilers that pretend to be GCC
On Tue, 31 Jan 2012, Ludovic Courtès wrote: Hi, Chris Lattner clatt...@apple.com skribis: On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote: Hello, Chris Lattner clatt...@apple.com skribis: If fact, some do: http://clang.llvm.org/docs/LanguageExtensions.html#feature_check That seems like a very useful approach to solve the problem. The docs say that ‘__has_builtin’ co. are macros. What do they expand to? 0 or 1. I understand. To put it another way, how are they defined? Compiler magic, like __LINE__ for instance? I am still not sure what you are asking... Interestingly enough: $ cat q.c __has_builtin $ clang -E q.c segfault -- Marc Glisse
Re: Dealing with compilers that pretend to be GCC
Hi, Marc Glisse marc.gli...@inria.fr skribis: On Tue, 31 Jan 2012, Ludovic Courtès wrote: Hi, Chris Lattner clatt...@apple.com skribis: On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote: Hello, Chris Lattner clatt...@apple.com skribis: If fact, some do: http://clang.llvm.org/docs/LanguageExtensions.html#feature_check That seems like a very useful approach to solve the problem. The docs say that ‘__has_builtin’ co. are macros. What do they expand to? 0 or 1. I understand. To put it another way, how are they defined? Compiler magic, like __LINE__ for instance? I am still not sure what you are asking... Interestingly enough: $ cat q.c __has_builtin $ clang -E q.c segfault Yes, that’s what I was asking. It makes me think that the old CPP predicates (info (gcc) Obsolete Features) would be more appropriate than compiler magic, with the caveat that they’re presumably not widely supported. Thanks, Ludo’.
Re: Dealing with compilers that pretend to be GCC
On Jan 31, 2012, at 4:58 AM, Marc Glisse wrote: The docs say that ‘__has_builtin’ co. are macros. What do they expand to? 0 or 1. I understand. To put it another way, how are they defined? Compiler magic, like __LINE__ for instance? I am still not sure what you are asking... Yes, they are compiler magic. __has_attribute() __has_extension() etc all work the same way as well. Interestingly enough: $ cat q.c __has_builtin $ clang -E q.c segfault Nice catch, fixed in r149397. Thanks! -Chris
Re: Dealing with compilers that pretend to be GCC
On Jan 31, 2012, at 5:15 AM, Ludovic Courtès wrote: Interestingly enough: $ cat q.c __has_builtin $ clang -E q.c segfault Yes, that’s what I was asking. It makes me think that the old CPP predicates (info (gcc) Obsolete Features) would be more appropriate than compiler magic, with the caveat that they’re presumably not widely supported. They are similar in spirit. The major difference between the two is that it is easy for __has_feature and friends gracefully degrade when a compiler doesn't support them, because you can do: #ifndef __has_builtin #define __has_builtin(x) 0 #endif in your code, but you can't do anything like this for #assertion. That and assertions don't have any coverage over the features that you're interested in, and the grammar doesn't have a good way to handle multiple cases like features/attributes/extensions/etc. -Chris
Re: Dealing with compilers that pretend to be GCC
Hello, Chris Lattner clatt...@apple.com skribis: On Jan 20, 2012, at 5:24 PM, Jonathan Wakely jwakely@gmail.com wrote: On 21 January 2012 00:32, Vincent Lefevre wrote: On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: May I politely suggest that this is the wrong place to complain about other compilers pretending to be GCC :) I think that's the fault of GCC, which should have defined a macro for each extension. And what about the fact other compilers haven't defined such a macro for each extension they implement, whether it comes from GCC or not, is that GCC's fault too? If fact, some do: http://clang.llvm.org/docs/LanguageExtensions.html#feature_check That seems like a very useful approach to solve the problem. The docs say that ‘__has_builtin’ co. are macros. What do they expand to? Thanks, Ludo’.
Re: Dealing with compilers that pretend to be GCC
On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote: Hello, Chris Lattner clatt...@apple.com skribis: On Jan 20, 2012, at 5:24 PM, Jonathan Wakely jwakely@gmail.com wrote: On 21 January 2012 00:32, Vincent Lefevre wrote: On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: May I politely suggest that this is the wrong place to complain about other compilers pretending to be GCC :) I think that's the fault of GCC, which should have defined a macro for each extension. And what about the fact other compilers haven't defined such a macro for each extension they implement, whether it comes from GCC or not, is that GCC's fault too? If fact, some do: http://clang.llvm.org/docs/LanguageExtensions.html#feature_check That seems like a very useful approach to solve the problem. The docs say that ‘__has_builtin’ co. are macros. What do they expand to? 0 or 1. -Chris
Re: Dealing with compilers that pretend to be GCC
On Thu, 19 Jan 2012, Ludovic Court�s wrote: It turns out that ICC manages to build a working GCC plug-in, so after I would say there is some conceptual confusion here (based on this sentence, without having looked at the autoconf macros you refer to). Logically there are two or three different compilers involved: * The compiler (host-x-target) into which a plugin would be loaded. This is the one that needs to be GCC. * The compiler (build-x-host) building the plugin. There is no particular reason it should need to be GCC, if sufficiently compatible with the compiler that built the host-x-target compiler that will load the plugin. * If you are testing a compiler for plugin support by running it in some way, that will be a build-x-target compiler that is intended to be configured in the same way as the final host-x-target compiler. Such a build-x-target compiler will be used to build target libraries in a Canadian cross build of GCC. So always think carefully about which compiler you wish to test - and what the relevant properties of that compiler are. -- Joseph S. Myers jos...@codesourcery.com
Re: Dealing with compilers that pretend to be GCC
On 24/01/12 17:32, Joseph S. Myers wrote: On Thu, 19 Jan 2012, Ludovic Court�s wrote: It turns out that ICC manages to build a working GCC plug-in, so after I would say there is some conceptual confusion here (based on this sentence, without having looked at the autoconf macros you refer to). Logically there are two or three different compilers involved: * The compiler (host-x-target) into which a plugin would be loaded. This is the one that needs to be GCC. * The compiler (build-x-host) building the plugin. There is no particular reason it should need to be GCC, if sufficiently compatible with the compiler that built the host-x-target compiler that will load the plugin. Users of the dragonegg plugin (what few there are!) are often confused by this, thinking that they need to build the plugin with the compiler into which the plugin is going to be loaded, which of course is not the case. In fact if the target compiler (host-x-target) is a cross-compiler, for example running on x86 and producing code for ppc, there is no way it can be used to compile the plugin, since that needs to run on x86 not on ppc. Ciao, Duncan. * If you are testing a compiler for plugin support by running it in some way, that will be a build-x-target compiler that is intended to be configured in the same way as the final host-x-target compiler. Such a build-x-target compiler will be used to build target libraries in a Canadian cross build of GCC. So always think carefully about which compiler you wish to test - and what the relevant properties of that compiler are.
Re: Dealing with compilers that pretend to be GCC
On 2012-01-21 13:58:53 +, Jonathan Wakely wrote: On 21 January 2012 13:42, Vincent Lefevre wrote: On 2012-01-21 01:24:19 +, Jonathan Wakely wrote: And what about the fact other compilers haven't defined such a macro for each extension they implement, whether it comes from GCC or not, is that GCC's fault too? But GCC implemented them first. I said whether it comes from GCC or not. GCC didn't first implement the extensions that don't come from GCC. I thought they were all coming from GCC (an impression partly given by the fact that ICC defines __GNUC__). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: Dealing with compilers that pretend to be GCC
On 22 January 2012 11:34, Vincent Lefevre wrote: On 2012-01-21 13:58:53 +, Jonathan Wakely wrote: On 21 January 2012 13:42, Vincent Lefevre wrote: On 2012-01-21 01:24:19 +, Jonathan Wakely wrote: And what about the fact other compilers haven't defined such a macro for each extension they implement, whether it comes from GCC or not, is that GCC's fault too? But GCC implemented them first. I said whether it comes from GCC or not. GCC didn't first implement the extensions that don't come from GCC. I thought they were all coming from GCC (an impression partly given by the fact that ICC defines __GNUC__). I now have no idea what this discussion is about so will leave it there.
Re: Dealing with compilers that pretend to be GCC
On Sat, 21 Jan 2012 01:32:29 +0100
Vincent Lefevre vincent+...@vinc17.org wrote:
On 2012-01-20 23:28:07 +, Jonathan Wakely wrote:
May I politely suggest that this is the wrong place to complain about
other compilers pretending to be GCC :)
I think that's the fault of GCC, which should have defined a macro
for each extension.
I agree with that. And I even hope that if GCC 4.7 defined several macros, one
for each
extensions, like e.g.
__GCC_HAVE_INDIRECT_GOTO__ for the goto *x; feature
__GCC_HAVE_STATEMENT_EXPR__ for statement expressions
etc then perhaps in several years other compilers would do likewise. We just
have to
document our features and their corresponding macros...
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 mine, sont seulement les miennes} ***
Re: Dealing with compilers that pretend to be GCC
On Fri, 20 Jan 2012, Dave Korn wrote: OTOH the entire point of autotools is that any toolchain (even GCC itself) sometimes has bugs or unimplemented features, and you just can't argue with the principle that the definitive test is always going to be try and use the feature and verify if it worked or not. Therefore autoconf tests should not just test __GNUC__, unless the only thing they're trying to be a test for is whether __GUNC__ is defined or not. That's very relevant for packages that are compiled and where you just install binaries and trivial headers. For libraries where headers contain non-trivial code (in C++, there may not even be a compiled part to the library), not so much. You can generate a config.h with autoconf, but then you need to install it. And if you use several compilers, or several versions of a compiler, or several sets of options from the same compiler, you get into a horrible mess. So we need to rely on preprocessor defines like __GNUC__ to identify what we can do. We could also write autoconf bits for users of the library to include in their configure.ac, but most users don't use autoconf for their project, and with recursive dependencies it would quickly get out of hand. -- Marc Glisse
Re: Dealing with compilers that pretend to be GCC
Hi Ludo,
For ICC, one can test __ICC. For instance, here's what we have in mpfr.h
(for the use of __builtin_constant_p and __extension__ ({ ... })):
#if defined (__GNUC__) !defined(__ICC) !defined(__cplusplus)
Yeah, but it’s a shame that those compilers define __GNUC__ without
supporting 100% of the GNU C extensions. With this approach, you would
also need to add !defined for Clang, PGI, and probably others.
even GCC may not support 100% of the GCC extensions! For example, you can
find hacked GCC's out there which disable nested function support by default
(I think Apple did this). Even more problematic IMO than testing __GNUC__ is
code that tests for particular versions of GCC. There are versions of GCC
which have backported features from more recent GCC's (eg: GNAT from Ada Core
Technologies is like this). I've seen this cause problems with code that
includes different header files depending on the gcc version, since the
compiler doesn't have the expected set of header files.
Ciao, Duncan.
Re: Dealing with compilers that pretend to be GCC
On 2012-01-21 01:24:19 +, Jonathan Wakely wrote: And what about the fact other compilers haven't defined such a macro for each extension they implement, whether it comes from GCC or not, is that GCC's fault too? But GCC implemented them first. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: Dealing with compilers that pretend to be GCC
Why not just implement the clang feature checking macros?
http://clang.llvm.org/docs/LanguageExtensions.html#feature_check
Besides fixing the whole problem that this thread identifies, it doesn't
require cramming tons of macros into the initial preprocessor state, speeding
up compiler startup time.
-Chris
On Jan 21, 2012, at 12:14 AM, Basile Starynkevitch bas...@starynkevitch.net
wrote:
On Sat, 21 Jan 2012 01:32:29 +0100
Vincent Lefevre vincent+...@vinc17.org wrote:
On 2012-01-20 23:28:07 +, Jonathan Wakely wrote:
May I politely suggest that this is the wrong place to complain about
other compilers pretending to be GCC :)
I think that's the fault of GCC, which should have defined a macro
for each extension.
I agree with that. And I even hope that if GCC 4.7 defined several macros,
one for each
extensions, like e.g.
__GCC_HAVE_INDIRECT_GOTO__ for the goto *x; feature
__GCC_HAVE_STATEMENT_EXPR__ for statement expressions
etc then perhaps in several years other compilers would do likewise. We just
have to
document our features and their corresponding macros...
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 mine, sont seulement les miennes} ***
Re: Dealing with compilers that pretend to be GCC
On Jan 20, 2012, at 5:24 PM, Jonathan Wakely jwakely@gmail.com wrote: On 21 January 2012 00:32, Vincent Lefevre wrote: On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: May I politely suggest that this is the wrong place to complain about other compilers pretending to be GCC :) I think that's the fault of GCC, which should have defined a macro for each extension. And what about the fact other compilers haven't defined such a macro for each extension they implement, whether it comes from GCC or not, is that GCC's fault too? If fact, some do: http://clang.llvm.org/docs/LanguageExtensions.html#feature_check -Chris
Re: Dealing with compilers that pretend to be GCC
On 21 January 2012 13:42, Vincent Lefevre wrote: On 2012-01-21 01:24:19 +, Jonathan Wakely wrote: And what about the fact other compilers haven't defined such a macro for each extension they implement, whether it comes from GCC or not, is that GCC's fault too? But GCC implemented them first. I said whether it comes from GCC or not. GCC didn't first implement the extensions that don't come from GCC.
Re: Dealing with compilers that pretend to be GCC
Chris Lattner clatt...@apple.com writes: Why not just implement the clang feature checking macros? http://clang.llvm.org/docs/LanguageExtensions.html#feature_check Yes, please. [Hopefully with a smidgen of cooperation regarding the actual feature names...] -miles -- Dawn, n. When men of reason go to bed.
Re: Dealing with compilers that pretend to be GCC
On 21 January 2012 13:55, Chris Lattner wrote: On Jan 20, 2012, at 5:24 PM, Jonathan Wakely jwakely@gmail.com wrote: On 21 January 2012 00:32, Vincent Lefevre wrote: On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: May I politely suggest that this is the wrong place to complain about other compilers pretending to be GCC :) I think that's the fault of GCC, which should have defined a macro for each extension. And what about the fact other compilers haven't defined such a macro for each extension they implement, whether it comes from GCC or not, is that GCC's fault too? If fact, some do: http://clang.llvm.org/docs/LanguageExtensions.html#feature_check Indeed, and it's a feature I like, well done :) I just think bashing GCC (rather than filing enhancement requests or contributing patches) for not doing the same is unproductive, and saying it's GCC's fault that not all compilers do the same doesn't even make sense.
Re: Dealing with compilers that pretend to be GCC
even GCC may not support 100% of the GCC extensions! For example, you can find hacked GCC's out there which disable nested function support by default (I think Apple did this). I'd think that such hacked versions aren't really GCC anymore. Even more problematic IMO than testing __GNUC__ is code that tests for particular versions of GCC. There are versions of GCC which have backported features from more recent GCC's (eg: GNAT from Ada Core Technologies is like this). Essentially every vendor is like this. And not only for GCC, but for the kernel, etc. But most of them do things properly and stay compatible. -- Eric Botcazou
Re: Dealing with compilers that pretend to be GCC
Dave Korn skrev 2012-01-20 01:15: *snip* That could be tricky because I guess you won't be able to use libtool at configure time. *snip* It's possible to use libtool at configure time, but you need to invoke LT_OUTPUT before you do so. Or is there a reason for that not to work in this case? Cheers, Peter
Re: Dealing with compilers that pretend to be GCC
On 20/01/2012 11:19, Peter Rosin wrote: Dave Korn skrev 2012-01-20 01:15: *snip* That could be tricky because I guess you won't be able to use libtool at configure time. *snip* It's possible to use libtool at configure time, but you need to invoke LT_OUTPUT before you do so. Or is there a reason for that not to work in this case? Not as far as I know, I just wasn't aware that you could generate the output script early. cheers, DaveK
Re: Dealing with compilers that pretend to be GCC
Hi Vincent,
Vincent Lefevre vincent+...@vinc17.org skribis:
For ICC, one can test __ICC. For instance, here's what we have in mpfr.h
(for the use of __builtin_constant_p and __extension__ ({ ... })):
#if defined (__GNUC__) !defined(__ICC) !defined(__cplusplus)
Yeah, but it’s a shame that those compilers define __GNUC__ without
supporting 100% of the GNU C extensions. With this approach, you would
also need to add !defined for Clang, PGI, and probably others.
Thanks,
Ludo’.
Re: Dealing with compilers that pretend to be GCC
Yeah, but it’s a shame that those compilers define __GNUC__ without supporting 100% of the GNU C extensions. With this approach, you would also need to add !defined for Clang, PGI, and probably others. Having worked on the other side for a while -- for a vendor whose compiler supported many but not all of GCC's extensions -- I claim that the problem is with the many examples of code out there that blindly test for __GNUC__ instead of testing for individual extensions. From the other vendor's point of view, it's nearly useless to support any of the GCC extensions if you don't also define __GNUC__, because most code out there will simply test for that macro. By defining the macro even if you don't support, for example, nested functions, you can still compile 99% of the code that uses the extensions. -cary
Re: Dealing with compilers that pretend to be GCC
On Fri, Jan 20, 2012 at 2:41 PM, Cary Coutant ccout...@google.com wrote: Yeah, but it’s a shame that those compilers define __GNUC__ without supporting 100% of the GNU C extensions. With this approach, you would also need to add !defined for Clang, PGI, and probably others. Having worked on the other side for a while -- for a vendor whose compiler supported many but not all of GCC's extensions -- I claim that the problem is with the many examples of code out there that blindly test for __GNUC__ instead of testing for individual extensions. From the other vendor's point of view, it's nearly useless to support any of the GCC extensions if you don't also define __GNUC__, because most code out there will simply test for that macro. By defining the macro even if you don't support, for example, nested functions, you can still compile 99% of the code that uses the extensions. If there were a defined way to test for extensions from within C (or C++), then this problem would be much reduced. Clang has something of a framework to query support for different features, and I drafted a proposal for something similar that would work across different compilers (with the intension of tracking C++11 features as they roll out), but that proposal went nowhere (I was too late for it to be useful for C++11 in any case). -- James
Re: Dealing with compilers that pretend to be GCC
2012/1/20 Ludovic Courtès: Yeah, but it’s a shame that those compilers define __GNUC__ without supporting 100% of the GNU C extensions. With this approach, you would also need to add !defined for Clang, PGI, and probably others. May I politely suggest that this is the wrong place to complain about other compilers pretending to be GCC :) If GCC added a __REALLY_GNUC__ macro the other compilers would define it, for exactly the same reasons they define __GNUC__
Re: Dealing with compilers that pretend to be GCC
Hi, James Dennett james.denn...@gmail.com skribis: If there were a defined way to test for extensions from within C (or C++), then this problem would be much reduced. Clang has something of a framework to query support for different features, and I drafted a proposal for something similar that would work across different compilers (with the intension of tracking C++11 features as they roll out), but that proposal went nowhere (I was too late for it to be useful for C++11 in any case). It would still be useful, though, and a net improvement over the catch-all __GNUC__. Ludo’.
Re: Dealing with compilers that pretend to be GCC
Hi, Cary Coutant ccout...@google.com skribis: Yeah, but it’s a shame that those compilers define __GNUC__ without supporting 100% of the GNU C extensions. With this approach, you would also need to add !defined for Clang, PGI, and probably others. Having worked on the other side for a while -- for a vendor whose compiler supported many but not all of GCC's extensions -- I claim that the problem is with the many examples of code out there that blindly test for __GNUC__ instead of testing for individual extensions. From the other vendor's point of view, it's nearly useless to support any of the GCC extensions if you don't also define __GNUC__, because most code out there will simply test for that macro. By defining the macro even if you don't support, for example, nested functions, you can still compile 99% of the code that uses the extensions. Thanks, I see. I think the problem is that __GNUC__ is (ab)used to refer to the GNU C language (any version), whereas it’s initially meant to refer to the compiler implementation. Maybe CPP assertions could be revived to test for single language features? Ludo’.
Re: Dealing with compilers that pretend to be GCC
On 20/01/2012 23:28, Jonathan Wakely wrote: 2012/1/20 Ludovic Courtès: Yeah, but it’s a shame that those compilers define __GNUC__ without supporting 100% of the GNU C extensions. With this approach, you would also need to add !defined for Clang, PGI, and probably others. May I politely suggest that this is the wrong place to complain about other compilers pretending to be GCC :) If GCC added a __REALLY_GNUC__ macro the other compilers would define it, for exactly the same reasons they define __GNUC__ I do agree with the proposition that if you pretend to be GCC, but don't do it completely and well enough, that's a bug that should be fixed in the compiler pretending to be GCC. OTOH the entire point of autotools is that any toolchain (even GCC itself) sometimes has bugs or unimplemented features, and you just can't argue with the principle that the definitive test is always going to be try and use the feature and verify if it worked or not. Therefore autoconf tests should not just test __GNUC__, unless the only thing they're trying to be a test for is whether __GUNC__ is defined or not. cheers, DaveK
Re: Dealing with compilers that pretend to be GCC
On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: May I politely suggest that this is the wrong place to complain about other compilers pretending to be GCC :) I think that's the fault of GCC, which should have defined a macro for each extension. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: Dealing with compilers that pretend to be GCC
On 21 January 2012 00:32, Vincent Lefevre wrote: On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: May I politely suggest that this is the wrong place to complain about other compilers pretending to be GCC :) I think that's the fault of GCC, which should have defined a macro for each extension. And what about the fact other compilers haven't defined such a macro for each extension they implement, whether it comes from GCC or not, is that GCC's fault too?
Re: Dealing with compilers that pretend to be GCC
Hi Ludo, A number of compilers claim to be GCC, without actually being GCC. This has come to a point where they can hardly be distinguished–until one actually tries to use them. this suggests that you shouldn't be testing for GCC, and instead should be testing for support for particular features. For example, to know if nested functions are supported you would have your configure script compile a mini program that uses nested functions. Ciao, Duncan. I had the following macro to determine whether plug-in support is available: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?view=markuprevision=5169root=starpupathrev=5202 The macro is fairly elaborate. Yet, ICC 12.0.1 and Clang 3.4 both pass the test, because: - They support ‘--version’; - They define ‘__GNUC__’, which defeats Autoconf’s ‘_AC_LANG_COMPILER_GNU’. - They support ‘-print-file-name’, and have ‘-print-file-name=plugin’ return GCC’s (!) plug-in header directory. To that end, ICC simply runs ‘gcc -print-file-name=plugin’, while Clang appears to be doing some guesswork. It turns out that ICC manages to build a working GCC plug-in, so after all, it may be “entitled” to define ‘__GNUC__’, in a broad sense. Conversely, Clang doesn’t support several GNU extensions, such as nested functions, so it quickly fails to compile code. Based on that, I modified my feature test like this: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpur1=5169r2=5203 I don’t see what can be done on “our” side (perhaps Autoconf’s feature test could be strengthened, but how?), but I wanted to document this state of affairs. Thanks, Ludo’.
Re: Dealing with compilers that pretend to be GCC
Hi Ducan, Duncan Sands baldr...@free.fr skribis: A number of compilers claim to be GCC, without actually being GCC. This has come to a point where they can hardly be distinguished–until one actually tries to use them. this suggests that you shouldn't be testing for GCC, and instead should be testing for support for particular features. For example, to know if nested functions are supported you would have your configure script compile a mini program that uses nested functions. Yes. The macro I posted is a feature test: it tests for plug-in header availability, and the availability of several GCC internal types and declarations. When I noticed that Clang doesn’t support nested functions, I added that to the test: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpur1=5169r2=5203 Yet, I can’t reasonably add a feature test for each GNU extension that GCC’s headers or my own code use. Maybe tomorrow Clang will support nested functions, while still lacking support for some other extension that’s needed. Thanks, Ludo’.
Re: Dealing with compilers that pretend to be GCC
Hi Ludo, I didn't really get it. Why do you want to know whether the compiler is GCC or not? Presumably because you have several versions of your code, one version using GCC feature XYZ and the other not using XYZ. If so, the logically correct (but maybe impractical) approach is to test if the compiler supports XYZ, and switch between the two code versions depending on that. For example if XYZ is nested functions, do you have a version of your code that uses nested functions and another that does not? If you don't have a version that works with compilers like clang that don't support nested functions, then why bother testing for nested function support? You will discover the lack of nested function support when your code fails to compile. Ciao, Duncan. On 19/01/12 15:39, Ludovic Courtès wrote: Hi Ducan, Duncan Sandsbaldr...@free.fr skribis: A number of compilers claim to be GCC, without actually being GCC. This has come to a point where they can hardly be distinguished–until one actually tries to use them. this suggests that you shouldn't be testing for GCC, and instead should be testing for support for particular features. For example, to know if nested functions are supported you would have your configure script compile a mini program that uses nested functions. Yes. The macro I posted is a feature test: it tests for plug-in header availability, and the availability of several GCC internal types and declarations. When I noticed that Clang doesn’t support nested functions, I added that to the test: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpur1=5169r2=5203 Yet, I can’t reasonably add a feature test for each GNU extension that GCC’s headers or my own code use. Maybe tomorrow Clang will support nested functions, while still lacking support for some other extension that’s needed. Thanks, Ludo’.
Re: Dealing with compilers that pretend to be GCC
On 01/19/12 06:24, Ludovic Courtès wrote: I don’t see what can be done on “our” side (perhaps Autoconf’s feature test could be strengthened, but how?) Which feature test would that be? I certainly understand the problem, and have run into issues where clang fools 'configure' into thinking a GCC feature is present when it isn't, but testing whether a compiler is GCC is not really the Autoconf Way. A 'configure' script is supposed to check for behavior, not identity. If the compiler supports the features needed, then generally speaking a 'configure' script shouldn't care whether the compiler is truly GCC.
Re: Dealing with compilers that pretend to be GCC
Hi Paul, Paul Eggert egg...@cs.ucla.edu skribis: A 'configure' script is supposed to check for behavior, not identity. If the compiler supports the features needed, then generally speaking a 'configure' script shouldn't care whether the compiler is truly GCC. Right. But how would you write feature tests that would check (1) whether the GNU C language is supported, and (2) whether GCC plug-ins are supported? That’s the problem I’m trying to solve. Thanks, Ludo’.
Re: Dealing with compilers that pretend to be GCC
Duncan Sands baldr...@free.fr skribis: Why do you want to know whether the compiler is GCC or not? Because I’m writing a plug-in for GCC. Ludo’.
RE: Dealing with compilers that pretend to be GCC
Write a test that checks for the existence of that machinery. I agree with the earlier comments. Checking version strings or program names is the wrong way, because you're essentially saying if it is X then I know it can do Y rather than directly asking the question can it do Y. The issue with if it is X then... is that a rule of that form is fragile. Even if it is correct today -- which is unlikely -- it WILL be wrong tomorrow. What matters for your purposes is can it do Y -- does it (1) support the language features you need, and (2) does it support the GCC plugin mechanism. If the answer to both questions is yes, then your code should work, and it doesn't matter one bit whether the compiler calls itself GCC or FOOCC. paul -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Ludovic Courtès Sent: Thursday, January 19, 2012 11:52 AM To: Paul Eggert Cc: gcc@gcc.gnu.org; bug-autoc...@gnu.org Subject: Re: Dealing with compilers that pretend to be GCC Hi Paul, Paul Eggert egg...@cs.ucla.edu skribis: A 'configure' script is supposed to check for behavior, not identity. If the compiler supports the features needed, then generally speaking a 'configure' script shouldn't care whether the compiler is truly GCC. Right. But how would you write feature tests that would check (1) whether the GNU C language is supported, and (2) whether GCC plug-ins are supported? That’s the problem I’m trying to solve. Thanks, Ludo’.
Re: Dealing with compilers that pretend to be GCC
On 19/01/2012 16:51, Ludovic Courtès wrote: Right. But how would you write feature tests that would check (1) whether the GNU C language is supported, Try and compile a conftest that uses it. If you wanted a possibly over-engineered solution, write one conftest for each feature of GNU C that you might want to use; otherwise maybe just write one conftest that uses as many different features as you can think of. and (2) whether GCC plug-ins are supported? Write a conftest that actually compiles a minimal basic gcc plugin, attempts to invoke the compiler with it, and looks for it to output Hello world or whatever. That could be tricky because I guess you won't be able to use libtool at configure time. Maybe you could just try invoking the compiler with the right options to load the lto-plugin, check that that works, then invoke it with a -plugin option pointing to a non-existent file name and make sure that that fails, just to be sure that the compiler is actually using the option flag and not just ignoring it. cheers, DaveK
Re: Dealing with compilers that pretend to be GCC
On 2012-01-19 15:58:22 +0100, Duncan Sands wrote:
Hi Ludo, I didn't really get it. Why do you want to know whether the compiler
is GCC or not? Presumably because you have several versions of your code,
one version using GCC feature XYZ and the other not using XYZ. If so, the
logically correct (but maybe impractical) approach is to test if the compiler
supports XYZ, and switch between the two code versions depending on that.
For example if XYZ is nested functions, do you have a version of your code
that uses nested functions and another that does not? If you don't have a
version that works with compilers like clang that don't support nested
functions, then why bother testing for nested function support? You will
discover the lack of nested function support when your code fails to compile.
I don't know whether Ludo can use this approach, but it not possible
when providing a header file for some library (e.g. MPFR's mpfr.h).
For ICC, one can test __ICC. For instance, here's what we have in mpfr.h
(for the use of __builtin_constant_p and __extension__ ({ ... })):
#if defined (__GNUC__) !defined(__ICC) !defined(__cplusplus)
--
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
