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 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
[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] (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] (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
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
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
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
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
; <[EMAIL PROTECTED]> on 11/02/2000 06:40:58 AM
To: Wayne Brown/Corporate/Altec@Altec
cc: [EMAIL PROTECTED]
Subject: Re: Where did kgcc go in 2.4.0-test10 ?
On Thu, 02 Nov 2000 06:46:04 [EMAIL PROTECTED] wrote:
>
>
> I've been following this kgcc discussion with int
> > 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
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
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.
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
On Thu, 02 Nov 2000 06:46:04 [EMAIL PROTECTED] wrote:
>
>
> I've been following this kgcc discussion with interest for weeks now and
> there's
> one thing that still puzzles me. Everyone on both sides of the issue seems to
> be saying that kgcc (AKA egcs 1.1.2) is used because the gcc versions
> Alan's message wasn't clear, but it seemed to imply that a patch to add
> this script to 2.4.x would be submitted to Linus. gcc 2.95.2 is a bit
> smarter about some things, and I definitely prefer using that compiler.
> I also prefer fixing 2.4.x kernel<->compiler bugs rather than defaulting
>
[EMAIL PROTECTED] wrote:
> What I haven't seen yet is
> an explanation of why kgcc can't be used for compiling *everything*
It can. But if we are talking about 2.4.x, I want my kernel built with
the improved gcc-2.95.2 -- unless there is a good reason not to do so --
and kgcc is egcs-1.1.2 not g
On Wed, Nov 01, 2000 at 04:54:18PM -0700, Cort Dougan wrote:
> Since you're setting yourself up as a proponent of this can you explain why
> RedHat includes a compiler that doesn't work with the kernel? Don't get
It actually does not compile only 2.2 kernels unless they are patched (the
patches
I've been following this kgcc discussion with interest for weeks now and there's
one thing that still puzzles me. Everyone on both sides of the issue seems to
be saying that kgcc (AKA egcs 1.1.2) is used because the gcc versions shipped by
several vendors don't compile the kernel correctly. Wh
Mike Galbraith wrote:
> [root]:# gcc -v
> Reading specs from /usr/lib/gcc-lib/i586-linux-gnu/gcc-2.95.2/specs
> gcc version gcc-2.95.2 19991024 (release)
> [root]:# gcc -V 2.8.1 -v
> Using builtin specs. <== danger Will Robinson. (think about includes etc)
> gcc driver version gcc-2.95.2 19991024
On Wed, 1 Nov 2000, Jeff Garzik wrote:
> Alan Cox wrote:
> > Mandrake kgcc I believe is egcs 1.1.2
>
> Correct...
>
> Though Richard Henderson's message recent about 'gcc -V ...' not doing
> the right thing has me worried... egcs 1.1.2 not gcc 2.95.2 is
> definitely being called when '/usr/bin
"J . A . Magallon" wrote:
>
> On Thu, 02 Nov 2000 02:12:31 Jeff Garzik wrote:
> >>
> > You're not changing 2.4.x to use kgcc, are you? It seems to be working
> > fine under gcc 2.95.2+fixes...
> >
>
> What means "using kgcc" ?
Alan has a script in 2.2.x which attempts to find the best compiler
On Thu, 02 Nov 2000 02:12:31 Jeff Garzik wrote:
>>
> You're not changing 2.4.x to use kgcc, are you? It seems to be working
> fine under gcc 2.95.2+fixes...
>
What means "using kgcc" ?. I think it should be done even before.
It is not using "egcs" as you seem to be thinking. You cant put your
Alan Cox wrote:
> J. A. Magallon wrote:
> > I have noticed that in latest patch for 2.4.0, the global Makefile
> > no more tries to find a kgcc, and falls back to gcc.
The global Makefile in 2.4.x -never- looked for kgcc.
> > I suppose because 2.7.2.3 is no more good for kernel, but still you
>
On Wed, Nov 01, 2000 at 06:04:38PM -0500, George wrote:
> On Wed, 1 Nov 2000, Kurt Garloff wrote:
> >kgcc is a redhat'ism. They invented this package because their 2.96 fails
> >compiling a stable kernel. However, it's not a good idea to dist specific
> >code into the official kernel tree.
>
> Bi
According to Jeff Garzik:
> Miquel van Smoorenburg wrote:
> > By default Debian comes
> > with gcc 2.95.2 which compiles current 2.2.x and 2.4.x kernels just
> > fine.
>
> Linux-Mandrake 7.2 doesn't seem to be missing gcc patches that
> Debian has... and in our testing we've found that some dr
H. Peter Anvin ([EMAIL PROTECTED]) said:
> I think at least supporting a "kgcc" compiler makes sense,
> conceptually (although it probably should have been called "kcc", but
> it's too late now.)
There was already some userland package named kcc, with a kcc
binary. A Kanji converter of some sort
> So other distro's did it too. Why did nobody complain till RedHat
> did it? Because no one else decided to use, as the default, a bleeding edge
> compiler that not only won't compile the kernel but won't even touch a lot of
> userspace code either.
Actually the first people to do exac
> } before on this list) and we didn't have time to implement and QA the
>
> Oh, my.
Doing the QA on a kernel change of compiler is a long hard process. It took
until 2.2.17 to apparently get a 2.2 kernel solid with gcc 2.95.
Alan
-
To unsubscribe from this list: send the line "unsubscribe lin
Followup to: <[EMAIL PROTECTED]>
By author:"David S. Miller" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> We already know we are a bunch of pinheads wrt. the userland compiler
> issue, full stop. It need not be restated several hundred more times.
> Believe me, after such a large
Miquel van Smoorenburg wrote:
> By default Debian comes
> with gcc 2.95.2 which compiles current 2.2.x and 2.4.x kernels just
> fine.
Linux-Mandrake 7.2 doesn't seem to be missing gcc patches that
Debian has... and in our testing we've found that some drivers are
still miscompiled by gcc 2.95.
In article <[EMAIL PROTECTED]>,
David S. Miller <[EMAIL PROTECTED]> wrote:
> Date: Wed, 1 Nov 2000 23:57:34 +0100
> From: Kurt Garloff <[EMAIL PROTECTED]>
>
> kgcc is a redhat'ism.
>
>Debian has it too.
Not quite. Debian does have an completely optional gcc272 package. It
is _not_ ins
On Wed, Nov 01, 2000 at 11:30:50PM +, Alan Cox wrote:
> > Yes, but what's more important is that all of these "kgcc" variants are
> > gcc 2.7.2.x-based (unless there's one I don't know about). And we don't want
> > 2.7.2.x, we want egcs 1.1.2 or newer (but not gcc 2.9x, unless you know what
>
> kgcc is a redhat'ism. They invented this package because their 2.96 fails
> compiling a stable kernel.
> However, it's not a good idea to dist specific code into the official kernel
> tree.
The changes in 2.2.18pre for picking the compiler are actually for multiple
distributions. The 'kgcc' con
On Wed, 1 Nov 2000, Kurt Garloff wrote:
>On Wed, Nov 01, 2000 at 11:40:58PM +0100, J . A . Magallon wrote:
>> I have noticed that in latest patch for 2.4.0, the global Makefile
>> no more tries to find a kgcc, and falls back to gcc.
>> I suppose because 2.7.2.3 is no more good for kernel, but sti
On Wed, Nov 01, 2000 at 11:40:58PM +0100, J . A . Magallon wrote:
> I have noticed that in latest patch for 2.4.0, the global Makefile
> no more tries to find a kgcc, and falls back to gcc.
> I suppose because 2.7.2.3 is no more good for kernel, but still you
> can use 2.91, 2.95.2 or 2.96(??). Is
> I have noticed that in latest patch for 2.4.0, the global Makefile
> no more tries to find a kgcc, and falls back to gcc.
> I suppose because 2.7.2.3 is no more good for kernel, but still you
> can use 2.91, 2.95.2 or 2.96(??). Is that a patch that leaked in
> the way to test10, or is for anothe
I have noticed that in latest patch for 2.4.0, the global Makefile
no more tries to find a kgcc, and falls back to gcc.
I suppose because 2.7.2.3 is no more good for kernel, but still you
can use 2.91, 2.95.2 or 2.96(??). Is that a patch that leaked in
the way to test10, or is for another reason ?
61 matches
Mail list logo
