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 th
ov 2000 16: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
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 th
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 fe
> "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
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 defe
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, th
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 k
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 "i
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.
> >
> >
ay, November 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 th
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 is
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 al
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 no
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 un
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 optimi
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 gc
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:
>
> > T
[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 h
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 t
[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
[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 th
[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 t
[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 k
[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
> 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 fro
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 tools
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 futur
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 perfectl
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 mov
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 t
Let me see if I understand you correctly. Metrowerks (Motorola) makes a
twenty something million dollar investment in your little company, and as
part of the agreement (not to mention Metrowerk's sole motivation) you are
required to create a version of Linux that compiles under their ANSI c too
| 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 de
Tim Riker wrote:
>
> 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
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 exis
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. In
"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 u
| 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 linux-
#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 wr
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 har
> 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 reasona
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 move
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 use
> > 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?
Then
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 the
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 threa
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 C
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 wo
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 userspa
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 software.
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 sof
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
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 so
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
> 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 ar
All,
Alright, I've been lurking long enough on this thread. What say we
consider the option of building the kernel with a compiler other than
gcc? This would imply a slightly different structure to the makefiles
and code.
There are two immediate reasons I can come up with for this:
1. There are
69 matches
Mail list logo
