Re: Dealing with compilers that pretend to be GCC

2012-02-02 Thread Miles Bader
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.

Re: Dealing with compilers that pretend to be GCC

2012-02-02 Thread Ludovic Courtès
Hi, Chris Lattner skribis: > On Jan 31, 2012, at 5:15 AM, Ludovic Courtès wrote: > >>> >>> Interestingly enough: >>> $ cat q.c >>> __has_builtin >>> $ clang -E q.c >>> >> >> Yes, that’s what I was asking. >> >> It makes me think that the old CPP predicates (info "(gcc) Obsolete >> Features")

Re: Dealing with compilers that pretend to be GCC

2012-01-31 Thread Chris Lattner
On Jan 31, 2012, at 5:15 AM, Ludovic Courtès wrote: >> >> Interestingly enough: >> $ cat q.c >> __has_builtin >> $ clang -E q.c >> > > 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 ma

Re: Dealing with compilers that pretend to be GCC

2012-01-31 Thread Chris Lattner
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 a

Re: Dealing with compilers that pretend to be GCC

2012-01-31 Thread Ludovic Courtès
Hi, Marc Glisse skribis: > On Tue, 31 Jan 2012, Ludovic Courtès wrote: > >> Hi, >> >> Chris Lattner skribis: >> >>> On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote: >>> Hello, Chris Lattner skribis: > If fact, some do: > http://clang.llvm.org/docs/LanguageExtensi

Re: Dealing with compilers that pretend to be GCC

2012-01-31 Thread Marc Glisse
On Tue, 31 Jan 2012, Ludovic Courtès wrote: Hi, Chris Lattner skribis: On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote: Hello, Chris Lattner skribis: If fact, some do: http://clang.llvm.org/docs/LanguageExtensions.html#feature_check That seems like a very useful approach to solve

Re: Dealing with compilers that pretend to be GCC

2012-01-31 Thread Ludovic Courtès
Hi, Chris Lattner skribis: > On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote: > >> Hello, >> >> Chris Lattner skribis: >> >>> On Jan 20, 2012, at 5:24 PM, Jonathan Wakely wrote: >>> On 21 January 2012 00:32, Vincent Lefevre wrote: > On 2012-01-20 23:28:07 +, Jonathan Wakely

Re: Dealing with compilers that pretend to be GCC

2012-01-30 Thread Chris Lattner
On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote: > Hello, > > Chris Lattner skribis: > >> On Jan 20, 2012, at 5:24 PM, Jonathan Wakely 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

Re: Dealing with compilers that pretend to be GCC

2012-01-30 Thread Ludovic Courtès
Hello, Chris Lattner skribis: > On Jan 20, 2012, at 5:24 PM, Jonathan Wakely 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 pret

Re: Dealing with compilers that pretend to be GCC

2012-01-24 Thread Duncan Sands
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).

Re: Dealing with compilers that pretend to be GCC

2012-01-24 Thread Joseph S. Myers
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 differe

Re: Dealing with compilers that pretend to be GCC

2012-01-22 Thread Jonathan Wakely
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

Re: Dealing with compilers that pretend to be GCC

2012-01-22 Thread Vincent Lefevre
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 GC

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Eric Botcazou
> 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__

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Jonathan Wakely
On 21 January 2012 13:55, Chris Lattner wrote: > On Jan 20, 2012, at 5:24 PM, Jonathan Wakely 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

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Miles Bader
Chris Lattner 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

2012-01-21 Thread Jonathan Wakely
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

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Chris Lattner
On Jan 20, 2012, at 5:24 PM, Jonathan Wakely 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'

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Chris Lattner
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 ti

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Vincent Lefevre
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 - Web:

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Duncan Sands
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 supportin

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Marc Glisse
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 wor

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Basile Starynkevitch
On Sat, 21 Jan 2012 01:32:29 +0100 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

Re: Dealing with compilers that pretend to be GCC

2012-01-20 Thread Jonathan Wakely
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 ea

Re: Dealing with compilers that pretend to be GCC

2012-01-20 Thread Vincent Lefevre
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 - Web:

Re: Dealing with compilers that pretend to be GCC

2012-01-20 Thread Dave Korn
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 pol

Re: Dealing with compilers that pretend to be GCC

2012-01-20 Thread Ludovic Courtès
Hi, Cary Coutant 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 v

Re: Dealing with compilers that pretend to be GCC

2012-01-20 Thread Ludovic Courtès
Hi, James Dennett 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

Re: Dealing with compilers that pretend to be GCC

2012-01-20 Thread Jonathan Wakely
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 compl

Re: Dealing with compilers that pretend to be GCC

2012-01-20 Thread James Dennett
On Fri, Jan 20, 2012 at 2:41 PM, Cary Coutant 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 si

Re: Dealing with compilers that pretend to be GCC

2012-01-20 Thread Cary Coutant
> 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

Re: Dealing with compilers that pretend to be GCC

2012-01-20 Thread Ludovic Courtès
Hi Vincent, Vincent Lefevre 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

Re: Dealing with compilers that pretend to be GCC

2012-01-20 Thread Dave Korn
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 be

Re: Dealing with compilers that pretend to be GCC

2012-01-20 Thread Peter Rosin
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 i

Re: Dealing with compilers that pretend to be GCC

2012-01-19 Thread Vincent Lefevre
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 co

Re: Dealing with compilers that pretend to be GCC

2012-01-19 Thread Dave Korn
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

RE: Dealing with compilers that pretend to be GCC

2012-01-19 Thread Paul_Koning
.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 skribis: > A 'configure' script is supposed to check for behavio

Re: Dealing with compilers that pretend to be GCC

2012-01-19 Thread Ludovic Courtès
Duncan Sands 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

2012-01-19 Thread Ludovic Courtès
Hi Paul, Paul Eggert 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 th

Re: Dealing with compilers that pretend to be GCC

2012-01-19 Thread Paul Eggert
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 G

Re: Dealing with compilers that pretend to be GCC

2012-01-19 Thread Duncan Sands
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

Re: Dealing with compilers that pretend to be GCC

2012-01-19 Thread Ludovic Courtès
Hi Ducan, Duncan Sands 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 > test

Re: Dealing with compilers that pretend to be GCC

2012-01-19 Thread Duncan Sands
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 featu

Dealing with compilers that pretend to be GCC

2012-01-19 Thread Ludovic Courtès
Hello, 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. I had the following macro to determine whether plug-in support is available: https://gforge.inria.fr/scm/viewvc.php/