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> Au
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 funct
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
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 abo
[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_NEST
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
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__
[...]
> "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
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
>> g
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 th
On Jul 3, 2008, at 10:01 AM, Andrew Haley wrote:
Chris Lattner wrote:
IMO, the whole notion of a compiler-specific macro has pretty limited
usefulness. Why not add macros for specific *features* offered by
the
compiler. For example:
#ifdef __SUPPORTS_NESTED_FUNCTIONS__
is much better t
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
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 complic
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 file
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:
>
> vi
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
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 incons
Vincent Lefevre <[EMAIL PROTECTED]> writes:
>> But that in turn does not matter, as if any non-gcc compiler *did* use
>> the gcc preprocessor, it would do so via gcc -E. In gcc, the
>> preprocessor is not a separate program.
>
> But in any case, there's a separate preprocessor: cpp. And perhaps c
Vincent Lefevre <[EMAIL PROTECTED]> writes:
> 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 comp
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 preprocessi
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 -
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
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
> 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 d
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
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
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 prepro
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).
> 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__"
> 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
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
> comp
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 see
> 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 M
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
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,
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
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 t
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 compiler
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 th
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 "defin
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"
41 matches
Mail list logo
