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)
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 ...
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
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
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:
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,
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 -
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
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:
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
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
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
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
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
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’.
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
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
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
44 matches
Mail list logo
