On Tue, 7 Nov 2000, David Lang wrote:
> Dick Johnson,
> earlier in the discussion there was a post of the 'incompatabilities'
> that were noted and one of the replies to that listed several c99 tools
> available to do the same job with the c99 syntax, so there are at least
> some cases where
:06:28 -0500 (EST)
> From: Richard B. Johnson <[EMAIL PROTECTED]>
> To: Tim Riker <[EMAIL PROTECTED]>
> Cc: Jes Sorensen <[EMAIL PROTECTED]>,
> Linux Kernel Mailing List <[EMAIL PROTECTED]>
> Subject: Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-t
On Tue, 7 Nov 2000, Tim Riker wrote:
> Jes,
>
> Hey how's Itanium been lately?
>
> As was mentioned before, there are nonproprietary compilers around as
> well that might be good choices. My point is that the ANSI C steering
> committee is probably a more balanced forum to determine C syntax
Jes,
Hey how's Itanium been lately?
As was mentioned before, there are nonproprietary compilers around as
well that might be good choices. My point is that the ANSI C steering
committee is probably a more balanced forum to determine C syntax than
the gcc team. We should adopt c99 syntax where
> "Tim" == Tim Riker <[EMAIL PROTECTED]> writes:
Tim> Alan Cox wrote:
>> > 1. There are architectures where some other compiler may do
>> better > optimizations than gcc. I will cite some examples here, no
>> need to argue
>>
>> I think we only care about this when they become free
"Tim" == Tim Riker [EMAIL PROTECTED] writes:
Tim Alan Cox wrote:
1. There are architectures where some other compiler may do
better optimizations than gcc. I will cite some examples here, no
need to argue
I think we only care about this when they become free software.
Tim This may be
On Tue, 7 Nov 2000, Tim Riker wrote:
Jes,
Hey how's Itanium been lately?
As was mentioned before, there are nonproprietary compilers around as
well that might be good choices. My point is that the ANSI C steering
committee is probably a more balanced forum to determine C syntax than
:28 -0500 (EST)
From: Richard B. Johnson [EMAIL PROTECTED]
To: Tim Riker [EMAIL PROTECTED]
Cc: Jes Sorensen [EMAIL PROTECTED],
Linux Kernel Mailing List [EMAIL PROTECTED]
Subject: Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)
On Tue, 7 Nov 2000, Tim Riker wrote:
Jes
On Tue, 7 Nov 2000, David Lang wrote:
Dick Johnson,
earlier in the discussion there was a post of the 'incompatabilities'
that were noted and one of the replies to that listed several c99 tools
available to do the same job with the c99 syntax, so there are at least
some cases where things
On Sun, Nov 05, 2000 at 06:01:29PM -0700, Tim Riker wrote:
> In short the impact of adding code to gcc that is not copyright FSF is
> minimal. Only the FSF copyrighted code would be defensible by the FSF. Any
> other code GPL violations would be the responsibility of the copyright
> owners to
On Sat, Nov 04, 2000 at 12:34:23AM -0500, Aaron Sethman wrote:
> > SGI's pro64 is free software and AFAIK is able to compile a kernel on IA64.
> > It is also not clear if gcc will ever produce good code on IA64.
>
> Well if its compiling the kernel just fine without alterations to the
> code,
Michael Meissner <[EMAIL PROTECTED]> said:
[...]
> Now people seem to be advocating moving the kernel to use features from C99
> that haven't even been coded yet (which mean when coded using the latest
> codegen as well). Note, I seriously doubt Linus will want a flag day (ie,
> after a given
In article <[EMAIL PROTECTED]> you write:
> In short, I do not see any enforceable advantages to the current FSF
> policies.
As a sidenote, this transfer of intellectual property of code is not
doable, according to French law (and other non-anglo-saxon countries).
In France, the author of a an
In article [EMAIL PROTECTED] you write:
In short, I do not see any enforceable advantages to the current FSF
policies.
As a sidenote, this transfer of intellectual property of code is not
doable, according to French law (and other non-anglo-saxon countries).
In France, the author of a an
Michael Meissner [EMAIL PROTECTED] said:
[...]
Now people seem to be advocating moving the kernel to use features from C99
that haven't even been coded yet (which mean when coded using the latest
codegen as well). Note, I seriously doubt Linus will want a flag day (ie,
after a given kernel
On Sat, Nov 04, 2000 at 12:34:23AM -0500, Aaron Sethman wrote:
SGI's pro64 is free software and AFAIK is able to compile a kernel on IA64.
It is also not clear if gcc will ever produce good code on IA64.
Well if its compiling the kernel just fine without alterations to the
code, then
Ion Badulescu <[EMAIL PROTECTED]> writes:
> On Sun, 5 Nov 2000 23:42:25 +0100, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> > On Sun, Nov 05, 2000 at 04:06:37PM -0500, Jakub Jelinek <[EMAIL PROTECTED]>
> wrote:
>
>
> >> for SGI, or SGI would have to be willing to assign some code to FSF.
> >
> >
er 05, 2000 1:18 PM
> To: Jakub Jelinek
> Cc: Alan Cox; Linux Kernel Mailing List
> Subject: Re: non-gcc linux?
>
>
> yes, exactly what my comments stated.
>
> Jakub Jelinek wrote:
> >
> > On Sun, Nov 05, 2000 at 01:52:24PM -0700, Tim Riker wrote:
> > >
My understand of the argument for assigning all gcc copyright to the FSF
is that this make 'gcc' easier to defend. My example of an sgi-gcc shows
that sgi-gcc would have different criteria in a defense. This is solely
because both SGI and FSF would hold copyrights.
Now Marc Lehmann claims that
Tim Riker <[EMAIL PROTECTED]> writes:
> I understand "will not", but "can not"? There is nothing stopping
> anyone, let's say SGI for example, from branching a separate gcc which
> would include copyrights assigned to FSF and other parties. Let's say
> this happens and a new sgigcc source base
On Sun, Nov 05, 2000 at 04:05:05PM -0700, Tim Riker <[EMAIL PROTECTED]> wrote:
> > Which can not and will not happen.
>
> I understand "will not", but "can not"? There is nothing stopping
As I explained three lines below the mail, if you care to read.
> would include copyrights assigned to FSF
On Sun, 5 Nov 2000 23:42:25 +0100, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 05, 2000 at 04:06:37PM -0500, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
>> for SGI, or SGI would have to be willing to assign some code to FSF.
>
> Which is the standard procedure that the FSF requires for
Marc Lehmann wrote:
>
> On Sun, Nov 05, 2000 at 04:06:37PM -0500, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> > That's hard to do, because the whole gcc has copyright assigned to FSF,
> > which means that either gcc steering committee would have to make an
> > exception from this
>
> Which can
Alan Cox wrote:
>
> > Perhaps I did not explain myself, or perhaps I misunderstand your
> > comments. I was responding to a comment that we could just copy some of
> > the optimizations from Pro64 over into gcc. Whether Pro64 understands
> > gcc syntax is immaterial to this question is it not?
>
> That's hard to do, because the whole gcc has copyright assigned to FSF,
> which means that either gcc steering committee would have to make an
> exception from this for SGI, or SGI would have to be willing to assign some
> code to FSF.
Or a third party decides its a silly situation and does it
> Perhaps I did not explain myself, or perhaps I misunderstand your
> comments. I was responding to a comment that we could just copy some of
> the optimizations from Pro64 over into gcc. Whether Pro64 understands
> gcc syntax is immaterial to this question is it not?
If gcc is architecturally
On Sun, Nov 05, 2000 at 04:06:37PM -0500, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> That's hard to do, because the whole gcc has copyright assigned to FSF,
> which means that either gcc steering committee would have to make an
> exception from this
Which can not and will not happen.
> for SGI,
yes, exactly what my comments stated.
Jakub Jelinek wrote:
>
> On Sun, Nov 05, 2000 at 01:52:24PM -0700, Tim Riker wrote:
> > Alan,
> >
> > Perhaps I did not explain myself, or perhaps I misunderstand your
> > comments. I was responding to a comment that we could just copy some of
> > the
On Sun, Nov 05, 2000 at 01:52:24PM -0700, Tim Riker wrote:
> Alan,
>
> Perhaps I did not explain myself, or perhaps I misunderstand your
> comments. I was responding to a comment that we could just copy some of
> the optimizations from Pro64 over into gcc.
That's hard to do, because the whole
Alan,
Perhaps I did not explain myself, or perhaps I misunderstand your
comments. I was responding to a comment that we could just copy some of
the optimizations from Pro64 over into gcc. Whether Pro64 understands
gcc syntax is immaterial to this question is it not?
Tim
Alan Cox wrote:
>
> >
[EMAIL PROTECTED] (Michael Meissner) wrote on 04.11.00 in
<[EMAIL PROTECTED]>:
> On Sat, Nov 04, 2000 at 02:24:00PM +0200, Kai Henningsen wrote:
> > [EMAIL PROTECTED] (Andi Kleen) wrote on 02.11.00 in
> > <[EMAIL PROTECTED]>:
> >
> > > again with a different syntax than gcc [I guess it would
[EMAIL PROTECTED] (Michael Meissner) wrote on 04.11.00 in
[EMAIL PROTECTED]:
On Sat, Nov 04, 2000 at 02:24:00PM +0200, Kai Henningsen wrote:
[EMAIL PROTECTED] (Andi Kleen) wrote on 02.11.00 in
[EMAIL PROTECTED]:
again with a different syntax than gcc [I guess it would have been too
Alan,
Perhaps I did not explain myself, or perhaps I misunderstand your
comments. I was responding to a comment that we could just copy some of
the optimizations from Pro64 over into gcc. Whether Pro64 understands
gcc syntax is immaterial to this question is it not?
Tim
Alan Cox wrote:
On Sun, Nov 05, 2000 at 01:52:24PM -0700, Tim Riker wrote:
Alan,
Perhaps I did not explain myself, or perhaps I misunderstand your
comments. I was responding to a comment that we could just copy some of
the optimizations from Pro64 over into gcc.
That's hard to do, because the whole gcc
yes, exactly what my comments stated.
Jakub Jelinek wrote:
On Sun, Nov 05, 2000 at 01:52:24PM -0700, Tim Riker wrote:
Alan,
Perhaps I did not explain myself, or perhaps I misunderstand your
comments. I was responding to a comment that we could just copy some of
the optimizations
On Sun, Nov 05, 2000 at 04:05:05PM -0700, Tim Riker [EMAIL PROTECTED] wrote:
Which can not and will not happen.
I understand "will not", but "can not"? There is nothing stopping
As I explained three lines below the mail, if you care to read.
would include copyrights assigned to FSF and
My understand of the argument for assigning all gcc copyright to the FSF
is that this make 'gcc' easier to defend. My example of an sgi-gcc shows
that sgi-gcc would have different criteria in a defense. This is solely
because both SGI and FSF would hold copyrights.
Now Marc Lehmann claims that
Ion Badulescu [EMAIL PROTECTED] writes:
On Sun, 5 Nov 2000 23:42:25 +0100, Marc Lehmann [EMAIL PROTECTED] wrote:
On Sun, Nov 05, 2000 at 04:06:37PM -0500, Jakub Jelinek [EMAIL PROTECTED]
wrote:
for SGI, or SGI would have to be willing to assign some code to FSF.
Which is the
On Sat, Nov 04, 2000 at 02:24:00PM +0200, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Andi Kleen) wrote on 02.11.00 in
><[EMAIL PROTECTED]>:
>
> > again with a different syntax than gcc [I guess it would have been too easy
> > to just use the gcc syntax]
>
> One of the big problems in C99 was
[EMAIL PROTECTED] (Tim Riker) wrote on 04.11.00 in <[EMAIL PROTECTED]>:
> Others that are commenting on the slow progress of some features in gcc
> should consider for themselves whether this position benefits the Open
> Source community or not.
Slow progress in gcc?
You know, I currently
[EMAIL PROTECTED] (Andi Kleen) wrote on 02.11.00 in
<[EMAIL PROTECTED]>:
> again with a different syntax than gcc [I guess it would have been too easy
> to just use the gcc syntax]
One of the big problems in C99 was that there was nobody on the committee
who really understood gcc well, so
[EMAIL PROTECTED] (Gábor Lénárt) wrote on 03.11.00 in
<[EMAIL PROTECTED]>:
> On Thu, Nov 02, 2000 at 02:27:35PM -0700, Tim Riker wrote:
> > #pragma is a particularly difficult problem to deal with because it is
> > non macro friendly. =(
> >
> > Sounds like C99 initializers are a likely first
[EMAIL PROTECTED] (Tim Riker) wrote on 02.11.00 in <[EMAIL PROTECTED]>:
> 1. C++ style comments
>
> Occurs in over 4000 lines of source and header files. :-( Should be
> converted to ansi c comments? We will probably want to just skirt this
> issue for now as the next rev of ANSI C is likely to
[EMAIL PROTECTED] (Alan Cox) wrote on 02.11.00 in
<[EMAIL PROTECTED]>:
> > How can I insure that the largest possible amount of my efforts benefit
> > the community at large? Hopefully this will make it easier to move to
> > C99 or any other future compiler porting project.
>
> The asm I dont
[EMAIL PROTECTED] (Christoph Hellwig) wrote on 02.11.00 in
<[EMAIL PROTECTED]>:
> In article <[EMAIL PROTECTED]> you wrote:
> > As is being discussed here, C99 has some replacements to the gcc syntax
> > the kernel uses. I believe the C99 syntax will win in the near future,
> > and thus the
> This is also a nice thought, but there is an obstacle.
> The Pro64 tools are Open Source and GPLed:
>
> http://oss.sgi.com/projects/Pro64/
>
> SGI retains the copyright to the code.
>
> As far as I know, the FSF owns the copyright to all code in the gcc
> suite. If improvements were taken
This is also a nice thought, but there is an obstacle.
The Pro64 tools are Open Source and GPLed:
http://oss.sgi.com/projects/Pro64/
SGI retains the copyright to the code.
As far as I know, the FSF owns the copyright to all code in the gcc
suite. If improvements were taken from the Pro64
Michael Meissner <[EMAIL PROTECTED]> writes:
> On Fri, Nov 03, 2000 at 10:19:12PM -0800, Russ Allbery wrote:
>> May I tentatively suggest that one point at which your resources could
>> productively be applied is towards improving the C99 compliance in gcc?
>> Clearly for the near to medium
On Fri, Nov 03, 2000 at 10:19:12PM -0800, Russ Allbery wrote:
> Tim Riker <[EMAIL PROTECTED]> writes:
>
> > Agreed. C99 does not replace all the needed gcc features. We should
> > start using the ones that make sense, and push for
> > standardization/documentation on the rest.
>
> > I'm
On Fri, Nov 03, 2000 at 10:19:12PM -0800, Russ Allbery wrote:
Tim Riker [EMAIL PROTECTED] writes:
Agreed. C99 does not replace all the needed gcc features. We should
start using the ones that make sense, and push for
standardization/documentation on the rest.
I'm perfectly happy with
Michael Meissner [EMAIL PROTECTED] writes:
On Fri, Nov 03, 2000 at 10:19:12PM -0800, Russ Allbery wrote:
May I tentatively suggest that one point at which your resources could
productively be applied is towards improving the C99 compliance in gcc?
Clearly for the near to medium future the
This is also a nice thought, but there is an obstacle.
The Pro64 tools are Open Source and GPLed:
http://oss.sgi.com/projects/Pro64/
SGI retains the copyright to the code.
As far as I know, the FSF owns the copyright to all code in the gcc
suite. If improvements were taken from the Pro64
This is also a nice thought, but there is an obstacle.
The Pro64 tools are Open Source and GPLed:
http://oss.sgi.com/projects/Pro64/
SGI retains the copyright to the code.
As far as I know, the FSF owns the copyright to all code in the gcc
suite. If improvements were taken from the
[EMAIL PROTECTED] (Christoph Hellwig) wrote on 02.11.00 in
[EMAIL PROTECTED]:
In article [EMAIL PROTECTED] you wrote:
As is being discussed here, C99 has some replacements to the gcc syntax
the kernel uses. I believe the C99 syntax will win in the near future,
and thus the gcc syntax
[EMAIL PROTECTED] (Gábor Lénárt) wrote on 03.11.00 in
[EMAIL PROTECTED]:
On Thu, Nov 02, 2000 at 02:27:35PM -0700, Tim Riker wrote:
#pragma is a particularly difficult problem to deal with because it is
non macro friendly. =(
Sounds like C99 initializers are a likely first target for
[EMAIL PROTECTED] (Tim Riker) wrote on 02.11.00 in [EMAIL PROTECTED]:
1. C++ style comments
Occurs in over 4000 lines of source and header files. :-( Should be
converted to ansi c comments? We will probably want to just skirt this
issue for now as the next rev of ANSI C is likely to
[EMAIL PROTECTED] (Alan Cox) wrote on 02.11.00 in
[EMAIL PROTECTED]:
How can I insure that the largest possible amount of my efforts benefit
the community at large? Hopefully this will make it easier to move to
C99 or any other future compiler porting project.
The asm I dont know - its
[EMAIL PROTECTED] (Tim Riker) wrote on 04.11.00 in [EMAIL PROTECTED]:
Others that are commenting on the slow progress of some features in gcc
should consider for themselves whether this position benefits the Open
Source community or not.
Slow progress in gcc?
You know, I currently have a
[EMAIL PROTECTED] (Andi Kleen) wrote on 02.11.00 in
[EMAIL PROTECTED]:
again with a different syntax than gcc [I guess it would have been too easy
to just use the gcc syntax]
One of the big problems in C99 was that there was nobody on the committee
who really understood gcc well, so the
On Sat, Nov 04, 2000 at 02:24:00PM +0200, Kai Henningsen wrote:
[EMAIL PROTECTED] (Andi Kleen) wrote on 02.11.00 in
[EMAIL PROTECTED]:
again with a different syntax than gcc [I guess it would have been too easy
to just use the gcc syntax]
One of the big problems in C99 was that there
Tim Riker <[EMAIL PROTECTED]> writes:
> Agreed. C99 does not replace all the needed gcc features. We should
> start using the ones that make sense, and push for
> standardization/documentation on the rest.
> I'm perfectly happy with this as a long term goal. I'll put what effort
> I can into
On Thu, 2 Nov 2000, Andi Kleen wrote:
> On Thu, Nov 02, 2000 at 07:07:12PM +, Alan Cox wrote:
> > > 1. There are architectures where some other compiler may do better
> > > optimizations than gcc. I will cite some examples here, no need to argue
> >
> > I think we only care about this when
| From: Jeff Garzik <[EMAIL PROTECTED]>
| Subject: Re: non-gcc linux?
|
| "D. Hugh Redelmeier" wrote:
| > Being GCC-dependent is rather parochial. Being GCC-version-dependent
| > is downright embarrassing.
| >
| > Summary: spurious GCC-isms are a bad thing.
|
In article <[EMAIL PROTECTED]> you write:
> There are two immediate reasons I can come up with for this:
I do not quite follow you on these two reasons. I daily work on an
Alpha machine, which runs under Linux, and I use the Compaq C compiler
since it gives better code on the applications I am
In article [EMAIL PROTECTED] you write:
There are two immediate reasons I can come up with for this:
I do not quite follow you on these two reasons. I daily work on an
Alpha machine, which runs under Linux, and I use the Compaq C compiler
since it gives better code on the applications I am
| From: Jeff Garzik [EMAIL PROTECTED]
| Subject: Re: non-gcc linux?
|
| "D. Hugh Redelmeier" wrote:
| Being GCC-dependent is rather parochial. Being GCC-version-dependent
| is downright embarrassing.
|
| Summary: spurious GCC-isms are a bad thing.
|
| Summary: You have no
On Thu, 2 Nov 2000, Andi Kleen wrote:
On Thu, Nov 02, 2000 at 07:07:12PM +, Alan Cox wrote:
1. There are architectures where some other compiler may do better
optimizations than gcc. I will cite some examples here, no need to argue
I think we only care about this when they become
Tim Riker [EMAIL PROTECTED] writes:
Agreed. C99 does not replace all the needed gcc features. We should
start using the ones that make sense, and push for
standardization/documentation on the rest.
I'm perfectly happy with this as a long term goal. I'll put what effort
I can into moving
On Thu, Nov 02, 2000 at 02:27:35PM -0700, Tim Riker wrote:
> #pragma is a particularly difficult problem to deal with because it is
> non macro friendly. =(
>
> Sounds like C99 initializers are a likely first target for integration.
>
> I'll keep plugging away at other stuff here as well.
I've
Ted
Agreed. C99 does not replace all the needed gcc features. We should
start using the ones that make sense, and push for
standardization/documentation on the rest.
I'm perfectly happy with this as a long term goal. I'll put what effort
I can into moving that direction without breaking the
Date: Thu, 02 Nov 2000 13:53:55 -0700
From: Tim Riker <[EMAIL PROTECTED]>
As is being discussed here, C99 has some replacements to the gcc syntax
the kernel uses. I believe the C99 syntax will win in the near future,
and thus the gcc syntax will have to be removed at some point.
"D. Hugh Redelmeier" wrote:
> Being GCC-dependent is rather parochial. Being GCC-version-dependent
> is downright embarrassing.
>
> Summary: spurious GCC-isms are a bad thing.
Summary: You have no clue about kernel<->gcc interdependencies and
issues.
> - use ISO C 89 when possible (without
| From: Tim Riker <[EMAIL PROTECTED]>
| However, it makes me a bit nervous to take this route. It assumes that
| the way gcc does things is the "best way". A more formal route of adding
| to the ANSI C standard would involve more eyes and therefore hopefully
| add to the quality of what has been
Excellent. I guess I really need to get a copy of the C99 spec
and dig through it.
http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI%2FISO%2FIEC+9899%2D1999
Thanx!
GCC does have a table of what's been implemented so far:
http://www.gnu.org/software/gcc/c99status.html
Which indicates
On Thu, Nov 02, 2000 at 02:27:35PM -0700, Tim Riker wrote:
> #pragma is a particularly difficult problem to deal with because it is
> non macro friendly. =(
When you assume C99 it is no problem, because C99 has _Pragma()
-Andi
-
To unsubscribe from this list: send the line "unsubscribe
#pragma is a particularly difficult problem to deal with because it is
non macro friendly. =(
Sounds like C99 initializers are a likely first target for integration.
I'll keep plugging away at other stuff here as well.
Andi Kleen wrote:
>
> On Thu, Nov 02, 2000 at 09:17:44PM +, Alan Cox
Do you or anyone else on the list recall why this decision was made? Can
you recall around when it was made so I can dig out the history from the
archives?
I would be eager to convert everything over to the C99 syntax, test the
heck out of it and submit the patch. Obviously this is wasted effort
On Thu, Nov 02, 2000 at 09:17:44PM +, Alan Cox wrote:
> > How can I insure that the largest possible amount of my efforts benefit
> > the community at large? Hopefully this will make it easier to move to
> > C99 or any other future compiler porting project.
>
> The asm I dont know - its a
> How can I insure that the largest possible amount of my efforts benefit
> the community at large? Hopefully this will make it easier to move to
> C99 or any other future compiler porting project.
The asm I dont know - its a hard problem. Things like C99 initializers for 2.5
seem quite a
Alan,
Alan Cox wrote:
>
> > > That need to run Linux - name one ? Why try to solve a problem when it hasn't
> > > happened yet. Let whoever needs to solve it do it.
> >
> > We have proposals here all under NDA. So I won't mention one of them.
> > Perhaps there are some of these folk on the list
In article <[EMAIL PROTECTED]> you wrote:
> As is being discussed here, C99 has some replacements to the gcc syntax
> the kernel uses. I believe the C99 syntax will win in the near future,
> and thus the gcc syntax will have to be removed at some point. In the
> interim the kernel will either
ok, a very valid point. The "C++ kernel code" reference is very telling.
(ouch). ;-)
Obviously the changes to support non-gcc compilers should have the goal
of minimal impact on gcc users lives. I recognize that the mainstream
will still use gcc.
Q: Why should we help you make it possible to
> > That need to run Linux - name one ? Why try to solve a problem when it hasn't
> > happened yet. Let whoever needs to solve it do it.
>
> We have proposals here all under NDA. So I won't mention one of them.
> Perhaps there are some of these folk on the list that would like to
> comment?
Date:Thu, 02 Nov 2000 12:31:51 -0700
From: Tim Riker <[EMAIL PROTECTED]>
Me or Alan? I did not mean this as a dig. I feel strongly that one
should have the choice here. I do not choose to enforce my beliefs on
anyone else. I am suggesting only that others should provide
On Thu, Nov 02, 2000 at 01:00:13PM -0700, Tim Riker wrote:
> This started off with some comments from the group (hpa in particular)
> that even between gcc releases, the gcc extensions have been much less
> stable that the standard compiler features. The danger of implementing
Given how the
In article <[EMAIL PROTECTED]> you wrote:
> You also forgot named structure initializers, but C99 supports them
> again with a different syntax than gcc [I guess it would have been too easy
> to just use the gcc syntax]
The named initializers syntax in C99 is from plan9, besides beeing probably
On Thu, Nov 02, 2000 at 11:55:55AM -0700, Tim Riker wrote:
> 1. C++ style comments
>
> Occurs in over 4000 lines of source and header files. :-( Should be
> converted to ansi c comments? We will probably want to just skirt this
> issue for now as the next rev of ANSI C is likely to include ANSI
Andrea Arcangeli wrote:
>
> On Thu, Nov 02, 2000 at 12:17:33PM -0700, Tim Riker wrote:
> > [..] by adding gcc
> > syntax into it [..]
>
> I think that's the right path. How much would be hard for you to add gcc syntax
> into your compiler too instead of feeding us kernel patches? Note that it
On Thu, Nov 02, 2000 at 12:17:33PM -0700, Tim Riker wrote:
> [..] by adding gcc
> syntax into it [..]
I think that's the right path. How much would be hard for you to add gcc syntax
into your compiler too instead of feeding us kernel patches? Note that it would
be a big advantage also for
Ben Ford wrote:
>
> Tim Riker wrote:
>
> > Alan Cox wrote:
> > >
> > > > 1. There are architectures where some other compiler may do better
> > > > optimizations than gcc. I will cite some examples here, no need to argue
> > >
> > > I think we only care about this when they become free
Andi Kleen wrote:
>
> On Thu, Nov 02, 2000 at 07:07:12PM +, Alan Cox wrote:
> > > 1. There are architectures where some other compiler may do better
> > > optimizations than gcc. I will cite some examples here, no need to argue
> >
> > I think we only care about this when they become free
Tim Riker wrote:
> Alan Cox wrote:
> >
> > > 1. There are architectures where some other compiler may do better
> > > optimizations than gcc. I will cite some examples here, no need to argue
> >
> > I think we only care about this when they become free software.
>
> This may be your belief, but
On Thu, Nov 02, 2000 at 07:07:12PM +, Alan Cox wrote:
> > 1. There are architectures where some other compiler may do better
> > optimizations than gcc. I will cite some examples here, no need to argue
>
> I think we only care about this when they become free software.
SGI's pro64 is free
Alan Cox wrote:
>
> > 1. There are architectures where some other compiler may do better
> > optimizations than gcc. I will cite some examples here, no need to argue
>
> I think we only care about this when they become free software.
This may be your belief, but I would not choose to enforce
> 1. There are architectures where some other compiler may do better
> optimizations than gcc. I will cite some examples here, no need to argue
I think we only care about this when they become free software.
> 2. There are architectures where gcc is not yet available, but vendor C
> compilers
1. There are architectures where some other compiler may do better
optimizations than gcc. I will cite some examples here, no need to argue
I think we only care about this when they become free software.
2. There are architectures where gcc is not yet available, but vendor C
compilers are.
Alan Cox wrote:
1. There are architectures where some other compiler may do better
optimizations than gcc. I will cite some examples here, no need to argue
I think we only care about this when they become free software.
This may be your belief, but I would not choose to enforce it on
On Thu, Nov 02, 2000 at 07:07:12PM +, Alan Cox wrote:
1. There are architectures where some other compiler may do better
optimizations than gcc. I will cite some examples here, no need to argue
I think we only care about this when they become free software.
SGI's pro64 is free
Andi Kleen wrote:
On Thu, Nov 02, 2000 at 07:07:12PM +, Alan Cox wrote:
1. There are architectures where some other compiler may do better
optimizations than gcc. I will cite some examples here, no need to argue
I think we only care about this when they become free software.
Tim Riker wrote:
Alan Cox wrote:
1. There are architectures where some other compiler may do better
optimizations than gcc. I will cite some examples here, no need to argue
I think we only care about this when they become free software.
This may be your belief, but I would not
1 - 100 of 120 matches
Mail list logo
