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 ?.
TIA
--
Juan Antonio Magallon Lacarta mailto:[email protected]
> 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 ?.
I've not yet submitted it to Linus is the obvious reason 8)
Alan
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 that a patch that leaked in
> the way to test10, or is for another reason ?.
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.
Regards,
--
Kurt Garloff <[email protected]> [Eindhoven, NL]
Physics: Plasma simulations <[email protected]> [TU Eindhoven, NL]
(See mail header or public key servers for RSA and DSA public keys.)
Date: Wed, 1 Nov 2000 23:57:34 +0100
From: Kurt Garloff <[email protected]>
kgcc is a redhat'ism.
Debian has it too.
Later,
David S. Miller
[email protected]
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 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 ?.
>
>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.
Big picture.
It may be distribution specific right now, but that doesn't stop other
distributions from needing it later.
--
-George Greer
(It's not like it's "redhat-gcc", which would qualify as specific.)
"David S. Miller" <[email protected]> writes:
> Date: Wed, 1 Nov 2000 23:57:34 +0100
> From: Kurt Garloff <[email protected]>
>
> kgcc is a redhat'ism.
>
> Debian has it too.
No, it uses the name gcc272:
blp:~(0)$ kgcc
bash: kgcc: command not found
blp:~(127)$ gcc272
gcc272: No input files
blp:~(1)$ cat /etc/debian_version
woody
blp:~(0)$
> kgcc is a redhat'ism.
> Debian has it too.
and conectiva
> 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' convention isnt a Red Hat invention btw. Its from
Conectiva.
Alan Cox wrote:
>
> > kgcc is a redhat'ism.
> > Debian has it too.
>
> and conectiva
And Mandrake, as of our recent 7.2 release. </me too>
Jeff
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft | dash and shrieking like a cheerleader."
| -Max
On Wed, Nov 01, 2000 at 02:47:21PM -0800, David S. Miller wrote:
> Date: Wed, 1 Nov 2000 23:57:34 +0100
> From: Kurt Garloff <[email protected]>
>
> kgcc is a redhat'ism.
>
> Debian has it too.
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
you're doing and are trying to fix the compiler. :)).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
From: Ben Pfaff <[email protected]>
Date: 01 Nov 2000 18:07:53 -0500
"David S. Miller" <[email protected]> writes:
> Debian has it too.
No, it uses the name gcc272:
I meant using a special compiler for kernel builds as opposed to
everything else.
Later,
David S. Miller
[email protected]
> 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
> you're doing and are trying to fix the compiler. :)).
Conectiva kgcc is egcs 1.1.2
Red Hat kgcc is egcs 1.1.2
Mandrake kgcc I believe is egcs 1.1.2
Debian gcc272 is gcc272
So the subset checking for kgcc is fine
On Wed, Nov 01, 2000 at 02:47:21PM -0800, David S. Miller wrote:
> kgcc is a redhat'ism.
>
> Debian has it too.
Debian doesn't have a kgcc, it's a gcc272, which is described as
follows:
"This is the old version of the GNU C compiler's C part. It should only be
used for backward compatibility purposes."
i don't have the gcc272 package installed under Debian, and i use the
standard compiler that comes with Debian (2.95.2) and it works fine on Intel
and Alpha for compiling 2.4 and 2.2, so there :P
<rant mode="flame">
This whole stupid 'kgcc' thing is yet another in a long line of really
dumb things that RedHat has done and it's just another reason i'm glad i
switched from RedHat to Debian.
<rant mode="off">
--
Nathan Paul Simons, Junior Software Engineer for FSMLabs
http://www.fsmlabs.com/
On Wed, Nov 01, 2000 at 11:30:50PM +0000, 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
> > you're doing and are trying to fix the compiler. :)).
>
> Conectiva kgcc is egcs 1.1.2
> Red Hat kgcc is egcs 1.1.2
> Mandrake kgcc I believe is egcs 1.1.2
heh, ok. i'm wrong. :)
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
Date: Wed, 1 Nov 2000 16:37:52 -0700
From: Nathan Paul Simons <[email protected]>
This whole stupid 'kgcc' thing is yet another in a long
line of really dumb things that RedHat has done and it's just
another reason i'm glad i switched from RedHat to Debian.
Please get your facts straight.
The rest of this thread will show you that this is not a "Red Hat
thing". Connectiva, Mandrake, and others do the same thing. In fact
we choose the name "kgcc" to match the convention set by these other
distributions.
Later,
David S. Miller
[email protected]
On Wed, 1 Nov 2000, David S. Miller wrote:
> Date: Wed, 1 Nov 2000 23:57:34 +0100
> From: Kurt Garloff <[email protected]>
>
> kgcc is a redhat'ism.
>
> Debian has it too.
If it has such (I don't know), then their own kgcc does not seem to have
confused users.
This let me propose to fix the above comments as follows:
The kgcc mess is a redhat-7'ism.
May-be, the kgcc thing is not a bad idea (I would obviously prefer to use
a single gcc release on a given system), but, as it is presented in redhat
7.0, it looks like a show-stopper given all that have been reported about.
A red dune's cap redhat should deserve for this one, in my opinion. ;-)
G?rard.
} Date: Wed, 1 Nov 2000 16:37:52 -0700
} From: Nathan Paul Simons <[email protected]>
}
} This whole stupid 'kgcc' thing is yet another in a long
} line of really dumb things that RedHat has done and it's just
} another reason i'm glad i switched from RedHat to Debian.
}
} Please get your facts straight.
}
} The rest of this thread will show you that this is not a "Red Hat
} thing". Connectiva, Mandrake, and others do the same thing. In fact
} we choose the name "kgcc" to match the convention set by these other
} distributions.
Good to see RedHat isn't a trail-blazer of ingenuity and will follow the
herd off the cliff. I'm "kgcc" agnostic, but your argument is weak.
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
grumpy about who did it first or what the old one is named but be clear
what I'm asking. I want to know if the 'gcc' on RedHat 7.0 fixes some
problems that the older compilers suffered from? If there's a good reason
for the new compiler that breaks with the kernel then great, it makes
sense. If it wasn't needed, then it's incredibly stupid.
Date: Wed, 1 Nov 2000 16:54:18 -0700
From: Cort Dougan <[email protected]>
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?
Because the kernel is buggy (the specifics of this has been discussed
before on this list) and we didn't have time to implement and QA the
changes needed in time for the 7.0 release.
Furthermore I was correcting Nathan's statement that this was a "Red
Hat thing", not specifically upholding the virtues of using a
different compiler for the kernel. That is a completely seperate
topic and we've had that taken that conversation as far as it will go
already remember? :-)
Finally, if I were to state "fsmlabs are a bunch of pinheads because
they did XXX" I would expect you to defend your employer as well if I
misrepresented them due to incorrect statements. Right? :-)
Later,
David S. Miller
[email protected]
} before on this list) and we didn't have time to implement and QA the
Oh, my.
On Wed, Nov 01, 2000 at 03:29:15PM -0800, David S. Miller wrote:
> Please get your facts straight.
>
> The rest of this thread will show you that this is not a "Red Hat
> thing". Connectiva, Mandrake, and others do the same thing. In fact
> we choose the name "kgcc" to match the convention set by these other
> distributions.
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.
--
Nathan Paul Simons, Junior Software Engineer for FSMLabs
http://www.fsmlabs.com/
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_ installed as kgcc (the binary is called gcc272) and you don't
_have_ to compile your kernels with it. It is an optional package and
you have to actively select and install it. By default Debian comes
with gcc 2.95.2 which compiles current 2.2.x and 2.4.x kernels just
fine. At least I haven't used gcc272 for kernels for at least a year now
(I think, first egcs, then gcc 2.95) and on all the servers I administer
(and that's quite a few) gcc 2.95 hasn't caused any problems.
Mike.
--
People get the operating system they deserve.
Date: Wed, 1 Nov 2000 17:11:58 -0700
From: Nathan Paul Simons <[email protected]>
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.
The topic is this thread is whether "kgcc" as a seperate compiler for
the kernel is a "Red Hat thing". You stated that it is, I am showing
you how it isn't. Please don't change the topic.
Red Hat's selection of it's userland compiler is an entirely different
topic and there have probably been a few hundred seperate flame wars
on this matter. Such a discussion does not belong here on the kernel
list. FWIW, I will be one of the first people to say that there were
some errors of judgment in the decision making that went on there.
Later,
David S. Miller
[email protected]
On Wed, Nov 01, 2000 at 03:45:24PM -0800, David S. Miller wrote:
> Finally, if I were to state "fsmlabs are a bunch of pinheads because
> they did XXX" I would expect you to defend your employer as well if I
> misrepresented them due to incorrect statements. Right? :-)
Dave,
i meant no personal affront to yourself or RedHat; i just thought i'd
let you know why myself (and i'm sure many others) don't use your distro
anymore. i did label that little comment with a "<rant mode="flame">", now
didn't i? ;)
BTW, if someone did say we were a bunch of pinheads, i'm sure we would
listen and ask "why?" then try to fix what was making us pinheads, not just
dismiss it by saying, "oh, everyone else is a pinhead too".
--
Nathan Paul Simons, Junior Software Engineer for FSMLabs
http://www.fsmlabs.com/
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/kgcc' is executed, but I'm still
worried that some details might be getting lost...
http://boudicca.tux.org/hypermail/linux-kernel/2000week44/1069.html
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft | dash and shrieking like a cheerleader."
| -Max
X-Coding-System: undecided-unix
Date: Wed, 1 Nov 2000 17:21:00 -0700
From: Nathan Paul Simons <[email protected]>
i meant no personal affront to yourself or RedHat; i just
thought i'd let you know why myself (and i'm sure many others)
don't use your distro anymore. i did label that little comment
with a "<rant mode="flame">", now didn't i? ;)
One is allowed to flame only if they get their facts
straight :-)
BTW, if someone did say we were a bunch of pinheads, i'm
sure we would listen and ask "why?" then try to fix what was making
us pinheads, not just dismiss it by saying, "oh, everyone else is a
pinhead too".
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 fiasco, we have listened :-)
But, on the other hand, to say that "kgcc" comceptually is something
only Red Hat has ever done is a factual error, that is all I am trying
to state, nothing more.
Later,
David S. Miller
[email protected]
Nathan Paul Simons wrote:
>
> On Wed, Nov 01, 2000 at 03:29:15PM -0800, David S. Miller wrote:
> > Please get your facts straight.
> >
> > The rest of this thread will show you that this is not a "Red Hat
> > thing". Connectiva, Mandrake, and others do the same thing. In fact
> > we choose the name "kgcc" to match the convention set by these other
> > distributions.
>
> 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.
Look, if you have an axe to grind about RedHat, do it somewhere else.
If you are wondering why there is one compiler to build the kernel and
one compiler to build everything else, for Mandrake at least, the reason
is stability. We never had problems with gcc 2.95.2+fixes for userland,
but there are isolated kernel cases in 2.2.x which still give us
problems. Therefore, our standard kernel is built with egcs 1.1.2, and
we provide that compiler to our users so they can avoid the same
problems.
Jeff
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft | dash and shrieking like a cheerleader."
| -Max
On Wed, Nov 01, 2000 at 05:11:58PM -0700, Nathan Paul Simons wrote:
> On Wed, Nov 01, 2000 at 03:29:15PM -0800, David S. Miller wrote:
> > Please get your facts straight.
> >
> > The rest of this thread will show you that this is not a "Red Hat
> > thing". Connectiva, Mandrake, and others do the same thing. In fact
> > we choose the name "kgcc" to match the convention set by these other
> > distributions.
>
> 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.
That's not quite true. gcc 2.96/7 isn't bad. It's just not intended for use
on production systems. But, it has a lot of things that people will have to
get used to for gcc 3.0. It also has a more robust/not-as-sucky C++ abi.
RedHat decided haveing a g++ that sucks less and including more compat
libraries in 7.1/whatever was worth it. I don't think so, but I'm not RedHat
:)
The idea of kgcc isn't a new one. It's been around, unoffically, since Linus
said "Ok, I'd recommend people use X compiler". It's now a more formal idea
and most x86 distributions have one now.
/me is glad he has more PPC boxes then x86 ones.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
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.
<checks> 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.2+fixes. I'm not so sure you are correct
here...
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft | dash and shrieking like a cheerleader."
| -Max
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 fiasco, we have listened :-)
>
> But, on the other hand, to say that "kgcc" comceptually is something
> only Red Hat has ever done is a factual error, that is all I am trying
> to state, nothing more.
>
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.)
The kernel uses a lot of gcc extensions, and history shows that these
extensions aren't as stable as the compiler system as a whole.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
> } 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
> 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 exactly that were Debian, who shipped a compiler
that couldnt reliably build a kernel for the time period. Thats one of the
reasons they put in gcc272.
Its good sense to tie large critical pieces of hard to validate code to the
compiler. There is a reason you'll find any good software company maintains
old releases in archives with the build environment to reproduce them exactly
Alan
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, IIRC.
Bill
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.
>
> <checks> 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.2+fixes. I'm not so sure you are correct
> here...
Really? Interesting! I'm not claiming I am completely correct, I'm
just stating what seems to be current Debian policy. Can you tell
me what drivers are miscompiled by 2.95.2, I'd appreciate that.
Mike.
--
People get the operating system they deserve.
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.
>
> Big picture.
>
> It may be distribution specific right now, but that doesn't stop other
> distributions from needing it later.
If number of distribution kernel-independent-compilers increase (and it
will, at least until gcc 2.97/3.0 branch stabilize), it will be better to
put in kernel variable (maybe in config) which cc to use. I agree, that this
is not the best thing to do - put such code in kernel, but if it'll be
needed, it can be done as shell script - 'which cc you want to compile
kernel ? (1) gcc (default) (2) kgcc .... (X) Other: ___'.
Jan Dvorak <[email protected]>
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
> > 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 ?.
>
> I've not yet submitted it to Linus is the obvious reason 8)
You're not changing 2.4.x to use kgcc, are you? It seems to be working
fine under gcc 2.95.2+fixes...
Jeff
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft | dash and shrieking like a cheerleader."
| -Max
On Wed, Nov 01, 2000 at 03:45:24PM -0800, "David S. Miller" <[email protected]> wrote:
> explain why RedHat includes a compiler that doesn't work with the
>
> Because the kernel is buggy (the specifics of this has been discussed
But redhat's compiler is much, much buggier, as has been discussed here
as well. Actually, redhat's gcc branch fails to compile a large amount of
userspace applications that aren't buggy.
I thought redhat already agreed that they made a bad decision in many
regards and the real reason for having the compiler was mere policy of not
switching the compiler duing a major release, and rehdat wanted to have a
newer compiler in any case.
...
> they did XXX" I would expect you to defend your employer as well if I
> misrepresented them due to incorrect statements. Right? :-)
Sometimes one just keeps quiet, and that's o.k.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [email protected] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
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
preferred compiler in kgcc.
Even I think it could include some general options for all the kernel build.
Think of packages like ALSA drivers grepping or analizing the kernel Makefile
to find that options are -fomit-frame-pointer -malign=xxxx and so on.
And that options can change from version to version of gcc.
Simpler: build a script (what kgcc is). An external module package, use kgcc.
--
Juan Antonio Magallon Lacarta mailto:[email protected]
"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 for
building your kernel. It looks for kgcc first, IIRC.
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
people to an older compiler.
> Think of packages like ALSA drivers grepping or analizing the kernel Makefile
> to find that options are -fomit-frame-pointer -malign=xxxx and so on.
> And that options can change from version to version of gcc.
> Simpler: build a script (what kgcc is). An external module package, use kgcc.
This is a totally separate issue. Choice of compiler is but one of many
variables. We need the build system to export all these variables, and
ALSA and other external packages will then pick up those settings for
use in their own builds. See for example
http://gtf.org/garzik/kernel/files/patches/2.4/2.4.0-test9/external-modules-2.4.0.9.8.patch.gz
Jeff
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft | dash and shrieking like a cheerleader."
| -Max
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/kgcc' is executed, but I'm still
> worried that some details might be getting lost...
> http://boudicca.tux.org/hypermail/linux-kernel/2000week44/1069.html
It's best to use a seperate driver for each compiler. I don't know of
any other way it can bite you, but one way is if you if you have drivers
built with different arch names trying to call the right compiler innards
with -V. You also need -b archname for it to get it right.
[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 (release) executing gcc version 2.8.1
[root]:# gcc -V 2.8.1 -b i486-linux-gnu -v
Reading specs from /usr/lib/gcc-lib/i486-linux-gnu/2.8.1/specs
gcc driver version gcc-2.95.2 19991024 (release) executing gcc version 2.8.1
I always diddle Makefile.in to build/install the driver with a non gcc
name for this reason. Each driver knows where it's innards lives without
needing to be told (and risking me accidentally telling it lies:)
-Mike
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 (release) executing gcc version 2.8.1
> [root]:# gcc -V 2.8.1 -b i486-linux-gnu -v
> Reading specs from /usr/lib/gcc-lib/i486-linux-gnu/2.8.1/specs
> gcc driver version gcc-2.95.2 19991024 (release) executing gcc version 2.8.1
Cool, looks like we are ok:
[jgarzik@rum linux_2_4]$ kgcc -v
Reading specs from
/usr/lib/gcc-lib/i586-mandrake-linux/egcs-2.91.66/specs
gcc driver version 2.95.3 19991030 (prerelease) executing gcc version
egcs-2.91.66
Thanks,
Jeff
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft | dash and shrieking like a cheerleader."
| -Max
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. What I haven't seen yet is
an explanation of why kgcc can't be used for compiling *everything* and why
another compiler even needs to be installed. I'm using egcs-1.1.2 with the
latest kernel, binutils, modutils, etc. as well as applications like the latest
ppp and setiathome with no problems. Instead of using two compilers, why not
stay with the older version for everything and not use the latest gcc for
anything until both the kernel and userland stuff can be compiled with it?
I'm not trying to fan the flames, just wondering why there's such an apparent
rush to upgrade to a newer gcc. Everyone seems to be taking it for granted that
an upgrade is needed, but there's disagreement on which version to use. Why do
we need to upgrade the compiler at all right now?
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 so that they can work with gcc we ship are available from H.J.'s
site).
With 2.4, the gcc we shipped just prints some wrong cpp warnings (which have
been fixed long time ago) but compiles a workable kernel.
The thing then is really about what is the recommended compiler for
compiling kernel, and it is egcs 1.1.2 at the moment, not 2.95.2, nor our
2.96, nor CVS head (the last one is known to miscompile some things in the
kernel on x86).
> grumpy about who did it first or what the old one is named but be clear
> what I'm asking. I want to know if the 'gcc' on RedHat 7.0 fixes some
> problems that the older compilers suffered from? If there's a good reason
Yes, it fixes several problems the older compilers suffered from, see Richard
Henderson's posting about this on lkml from end of September.
Jakub
[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 gcc-2.95.2 on my system.
> and why
> another compiler even needs to be installed.
Cuz the kernel should not dictate the compiler choice for the entire
distro.
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft | dash and shrieking like a cheerleader."
| -Max
> 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
> people to an older compiler.
I haven't submitted it. Im happy to do so if people want it in.
> ppp and setiathome with no problems. Instead of using two compilers, why not
> stay with the older version for everything and not use the latest gcc for
> anything until both the kernel and userland stuff can be compiled with it?
egcs-1.1.2 is a reasonable C compiler. It makes a few errors under register
pressure and stuff. However its at best 'a C++ subset compiler'. 2.95 is a
fair bit better.
Most of these problems are also not the compiler but applications. gcc 2.95
broke a lot of asm using code because the apps were wrong. Without the pain
they would simply never get fixed
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 shipped
^^^^^^^^^^^^^^^
Wrong assumption. The idea is if I need a way to set a compiler for kernel
that is not the same compiler as the system wide one. Should kernel Makefiles
use gcc (hardcoded) (and people must have a 'gcc' that works for kernel), or
let kernel use something called 'kgcc', and let user decide if in his machine
kgcc is 2.7, egcs or 2.95.2.
> by
> several vendors don't compile the kernel correctly. What I haven't seen yet
> is
> an explanation of why kgcc can't be used for compiling *everything* and why
> another compiler even needs to be installed.
Because gcc is not only the C compiler, is the full compiler system.
The support for C++ in 2.95 has nothing to do with egcs. And 2.95 supports
java, for example.
And the libraries. The C++ standard library is much better in 2.95 that in
egcs.
--
Juan Antonio Magallon Lacarta mailto:[email protected]
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 architectures where some other compiler may do better
optimizations than gcc. I will cite some examples here, no need to argue
out the point unless you disagree with the POSSIBILITY that this may be
true on at least one architecture. Anyway, possibilities include
Compaq's compiler on alpha, HP's compiler on hppa, Intel's compiler (or
rather plugins to another vendors compiler) on ia64, Metrowerk's
compiler on PPC, etc.
2. There are architectures where gcc is not yet available, but vendor C
compilers are.
I suggest that we avoid gcc extensions as much as possible, barring
performance hits. When there is an ANSI way of doing things we should
choose that route. Where there is not, then isolate the gcc way such
that compiler vendors can either:
1. implement the gcc way and conditional compile that code.
2. implement some other way and easily add that conditional code.
I've been looking into this here at Lineo for some of these vendors.
Here is a brief list of things I've come across:
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++
style comments.
2. Inline assembly statements
mostly in arch/ tree. Frequently used in macros as well. Much of this
will incur performance penalties if moved to external assembly files.
Some would require moving supported C code over as well. Hence many of
these will probably translate into conditional compilation based on the
compiler to avoid and performance hit for the mainstream case.
3. Declaring attributes of functions
The __attribute__ options: noreturn, const, format, section,
constructor, destructor, unused, and weak. weak and section are needed.
The rest can be ignored? These might want to be converted to #defines
such that alternative compilers can implement them differently.
4. Specifying attributes of variables
The __attribute__ options: aligned, packed, section and weak. As above
these will likely be #defines to handle different compiler syntax.
5. Conditionals with omitted operands
The missing operands should just be added into the mainstream source.
6. Referring to a type with typeof
no recommendation yet.
7. Macros with variable numbers of arguments
no recommendation yet.
8. Inquiring on alignment of types or variables (__alignof__)
no recommendation yet.
Well, I got a bit more long winded than I planned, but there it is.
Thoughts?
"H. Peter Anvin" wrote:
>
> 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 fiasco, we have listened :-)
> >
> > But, on the other hand, to say that "kgcc" comceptually is something
> > only Red Hat has ever done is a factual error, that is all I am trying
> > to state, nothing more.
> >
>
> 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.)
>
> The kernel uses a lot of gcc extensions, and history shows that these
> extensions aren't as stable as the compiler system as a whole.
>
> -hpa
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
> 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.
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.
Alan
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
everyone. Thank you for you opinion.
> > 2. There are architectures where gcc is not yet available, but vendor C
> > compilers are.
>
> 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?
>
> Alan
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
On Thu, Nov 02, 2000 at 07:07:12PM +0000, 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 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.
-Andi
Andi Kleen wrote:
>
> On Thu, Nov 02, 2000 at 07:07:12PM +0000, 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 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.
>
> -Andi
A grand example I should have included. Thanx! Last I knew the status
was that SGI had built the kernel with thier compiler, by adding gcc
syntax into it, but had not reached the point where the kernel would
run. Perhaps they have gotten past this. Since I'm no longer involved in
the Trillian (read ia64 Linux Project) mailing lists or weekly phone
calls I have been out of this loop for a month or so.
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
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 choose to enforce it on
> everyone. Thank you for you opinion.
No need to be so flip about it. I believe that most of us feel that way.
-b
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.
> >
> > This may be your belief, but I would not choose to enforce it on
> > everyone. Thank you for you opinion.
>
> No need to be so flip about it. I believe that most of us feel that way.
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 same
courtesy. I truly meant "Thank you for you opinion". I feel the
community benefits from the differing opinions contained within it.
>
> -b
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
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 userspace (not only kernel uses inline asm and
other gcc extensions). And probably it would be an improvement to your
compiler too (since I don't know of other compilers that are as smart as
gcc in the inline asm syntax :).
Andrea
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 would
> be a big advantage also for userspace (not only kernel uses inline asm and
> other gcc extensions). And probably it would be an improvement to your
> compiler too (since I don't know of other compilers that are as smart as
> gcc in the inline asm syntax :).
>
> Andrea
I agree there is much that can be done by taking this path. Lineo is
also pursuing this with the compiler vendors. Along the same lines, a
vendor may choose to implement a gcc front end that translates gcc
syntax. All these options have merit.
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 done solely for gcc.
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
gcc extensions in another compiler is that these feature are solely
under the control of the gcc team. They are to a large degree
"documented as implemented" and as such can be difficult to determine
the Right Way to implement. The Good Things that are in gcc, that we
believe are implemented the Right Way should probably be added to the
ANSI C spec. The others should be avoided, especially when there is an
existing ANSI C way to do them.
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
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++
> style comments.
First C99 includes C++ comments and it is more or less the "ANSI-C" now.
I also have my doubts that it is a real portability problem in practice,
it is such a common extension that most compilers I know have some switch
to enable it and even if they didn't it would be trivial to write a small
wrapper to remove them.
>
> 2. Inline assembly statements
>
> mostly in arch/ tree. Frequently used in macros as well. Much of this
> will incur performance penalties if moved to external assembly files.
> Some would require moving supported C code over as well. Hence many of
> these will probably translate into conditional compilation based on the
> compiler to avoid and performance hit for the mainstream case.
That will not work out. Linux without some form of inline assembly
sounds very unlikely. In theory you could maybe write wrappers for some
common inline assembly idioms, but in the end you'll likely need to duplicate
some files in asm/ and arch/
> 7. Macros with variable numbers of arguments
>
> no recommendation yet.
ISO C99 has a replacement, unfortunately not gcc compatible. gcc3+ supports
it, but you would drop compatibility to older gcc releases [which would
not make you very popular..]
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]
-Andi (who would much like to use C99 mixed statements/declarations in the kernel,
but not even gcc3 supports it yet)
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
older, it is from the C creators and more logic ;)
I think that are enough reasons for the ANSI people to not choose the GCC
syntax.
Christoph
--
Always remember that you are unique. Just like everyone else.
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 thread started I'm uncertain if with "stable" he meant "bug-free"
or "same API". You certainly mean "same API" and I see your point, OTOH
supporting gcc extensions still looks like the best solution to me - even if we
lack the standardization - because: 1) if you try to change the kernel I think
you'll get even more mainteinance troubles :), 2) the stable kernels never get
compiled with the bleeding edge gcc, so you would have plenty of time to
catchup any potential change in the gcc extensions.
Andrea
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 same
courtesy. I truly meant "Thank you for you opinion". I feel the
community benefits from the differing opinions contained within it.
Yes, but that argument doesn't hold once you start asking the everyone
to work on making that choice available. The question that some part of
the community may ask is --- why should we help you make it possible to
use a propietary C compiler?
Choice also implies a choice not to work on things which help some
particular person's pet cause, whether that is C++ kernel code, or
propietary C compilers. If it makes the code harder to maintain or more
complex, it impacts everyone, and it's fair to ask the question whether
or not the feeling "one should have the choice here" is worth the cost
which you're asking everyone to bear.
- Ted
> > 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 I think it will be up to you to achieve the non gcc build or to teach
your compiler gcc extensions (which may or may not be easier). The kernel also
tends to know a few things about how gcc optimises code which shouldn't matter
if your compiler is good enough to optimise nicely anyway.
AFAIK the only non gcc port of Linux isnt exactly a port but was ELKS done using
bcc86 (Bruce Evans compiler)
Alan
A number of people have pointed out to me that egcs-1.1.2 is weak on C++
support. Rather than clutter up the list by replying to all of them, I've
picked this one to say "Thank you" to everyone who responded. I'm not a C++
programmer, so I tend to forget about it and think of gcc as just a C compiler.
Now this discussion makes more sense to me.
I agree that if there is going to be a separate compiler for the kernel, the
Makefiles should be flexible enough to allow the user to plug in whatever
compiler he or she prefers to use.
Wayne
"J . A . Magallon" <[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 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
^^^^^^^^^^^^^^^
Wrong assumption. The idea is if I need a way to set a compiler for kernel
that is not the same compiler as the system wide one. Should kernel Makefiles
use gcc (hardcoded) (and people must have a 'gcc' that works for kernel), or
let kernel use something called 'kgcc', and let user decide if in his machine
kgcc is 2.7, egcs or 2.95.2.
> by
> several vendors don't compile the kernel correctly. What I haven't seen yet
> is
> an explanation of why kgcc can't be used for compiling *everything* and why
> another compiler even needs to be installed.
Because gcc is not only the C compiler, is the full compiler system.
The support for C++ in 2.95 has nothing to do with egcs. And 2.95 supports
java, for example.
And the libraries. The C++ standard library is much better in 2.95 that in
egcs.
--
Juan Antonio Magallon Lacarta mailto:[email protected]
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 a proprietary C
compiler?
This is right on the money. I hope to show that is is all part of "World
Domination". ;-) I can easily see other paths to get there though, so
why this one?
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 towards supporting both, or a
quantum jump to support the new gcc3+ compiler only. I am hoping a
little thought can get put into this such that this change will be less
painful down the road.
I hope that I can lend some time to this project and save the rest of
the community time in the long run. Benefit our projects in the short
term. And impact the rest of the linux-kernel community as little as
possible in the short term.
How does that sound for a way forward?
"Theodore Y. Ts'o" wrote:
>
> 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 same
> courtesy. I truly meant "Thank you for you opinion". I feel the
> community benefits from the differing opinions contained within it.
>
> Yes, but that argument doesn't hold once you start asking the everyone
> to work on making that choice available. The question that some part of
> the community may ask is --- why should we help you make it possible to
> use a propietary C compiler?
>
> Choice also implies a choice not to work on things which help some
> particular person's pet cause, whether that is C++ kernel code, or
> propietary C compilers. If it makes the code harder to maintain or more
> complex, it impacts everyone, and it's fair to ask the question whether
> or not the feeling "one should have the choice here" is worth the cost
> which you're asking everyone to bear.
>
> - Ted
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
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 towards supporting both, or a
> quantum jump to support the new gcc3+ compiler only. I am hoping a
> little thought can get put into this such that this change will be less
> painful down the road.
BTW: the C99 syntax for named structure initializers is supported from
gcc 2.7.<something> on. But a policy decision has been take to use
gcc synta in kernel.
Christoph
--
Always remember that you are unique. Just like everyone else.
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 that would like to
> > comment?
>
> Then I think it will be up to you to achieve the non gcc build or to teach
> your compiler gcc extensions (which may or may not be easier). The kernel also
> tends to know a few things about how gcc optimises code which shouldn't matter
> if your compiler is good enough to optimise nicely anyway.
This is completely reasonable. I guess what I'm asking is:
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.
>
> AFAIK the only non gcc port of Linux isnt exactly a port but was ELKS done using
> bcc86 (Bruce Evans compiler)
I have not looked at this project. Thank you for the pointer. I hope to
learn form their experiences.
>
> Alan
PS, while I'm writing to you. I reread my earlier reply to you and Ben
was right about chewing me out for it. My bad.
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
> 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 reasonable change. There are also things like partial structure
packing with __attribute((packed)) that can be hard to port
On Thu, Nov 02, 2000 at 09:17:44PM +0000, 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 hard problem. Things like C99 initializers for 2.5
> seem quite a reasonable change. There are also things like partial structure
> packing with __attribute((packed)) that can be hard to port
All non toy compilers[1] I've seen so far had some equivalent of __attribute__((packed)).
It just always has a different syntax, usually even non macro friendly (#pragma)
-Andi
[1] ok and the TenDRA one
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 if
there is a good reason to continue using the gcc syntax.
Christoph Hellwig wrote:
>
> 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 towards supporting both, or a
> > quantum jump to support the new gcc3+ compiler only. I am hoping a
> > little thought can get put into this such that this change will be less
> > painful down the road.
>
> BTW: the C99 syntax for named structure initializers is supported from
> gcc 2.7.<something> on. But a policy decision has been take to use
> gcc syntax in kernel.
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
#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 +0000, 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 hard problem. Things like C99 initializers for 2.5
> > seem quite a reasonable change. There are also things like partial structure
> > packing with __attribute((packed)) that can be hard to port
>
> All non toy compilers[1] I've seen so far had some equivalent of __attribute__((packed)).
> It just always has a different syntax, usually even non macro friendly (#pragma)
>
> -Andi
>
> [1] ok and the TenDRA one
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
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
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 gcc all ready supports this? I have not yet dug into
which pragmas though... ;-)
Andi Kleen wrote:
>
> 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
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
| 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 done solely for gcc.
|
| 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
| gcc extensions in another compiler is that these feature are solely
| under the control of the gcc team. They are to a large degree
| "documented as implemented" and as such can be difficult to determine
| the Right Way to implement. The Good Things that are in gcc, that we
| believe are implemented the Right Way should probably be added to the
| ANSI C spec. The others should be avoided, especially when there is an
| existing ANSI C way to do them.
I strongly support Tim's direction here.
I've found that code improves when you port it to different compilers
(unless you are in a hurry -- then it grows warts).
Being GCC-dependent is rather parochial. Being GCC-version-dependent
is downright embarrassing.
Summary: spurious GCC-isms are a bad thing.
Earlier, Tim gave quite a good outline of how to address GCCisms.
My summary:
- use ISO C 89 when possible (without undue pain)
- use IOS C 99 when advantageous
- use GCCisms for the remainder of appropriate things BUT embed them
in macros defined in header so that they can be systematically
replaced. Using these macros probably makes the code more readable.
Use of any GCCism should probably be justified in commentary.
This would improve the code *and* make it more portable.
The important advantages accrue to everyone, including those who never
use a different compiler.
Hugh Redelmeier
[email protected] voice: +1 416 482-8253
PS: I don't agree with all that ISO SC22 WG14 does, but I think that
its work is valuable. I attended their meeting in Toronto a couple of
weeks ago.
PPS: my own C compiler is not a toy and does not implement "packed".
I've not even thought of trying it on the linux kernel, but experience
shows that putting a program through my compiler does point to places
to improve the code. Ask Miguel de Icaza, for example.
On Wed, 1 Nov 2000, David S. Miller wrote:
> Date: Wed, 1 Nov 2000 16:54:18 -0700
> From: Cort Dougan <[email protected]>
>
> 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?
>
> Because the kernel is buggy (the specifics of this has been discussed
Every software seems to be buggy and gcc does not seem to be better than
the kernel in this area.
> before on this list) and we didn't have time to implement and QA the
> changes needed in time for the 7.0 release.
>
> Furthermore I was correcting Nathan's statement that this was a "Red
> Hat thing", not specifically upholding the virtues of using a
> different compiler for the kernel. That is a completely seperate
> topic and we've had that taken that conversation as far as it will go
> already remember? :-)
You were just claiming that other main Linux packagers do also suggest a
different compiler version for the kernel, which was only part of the
facts that let RedHat 7 have been loose with its kgcc/gcc mess.
And since it seems that everybody can build a Linux based package in his
garage and then find morons to buy it, let me ask my mother-in-law if
she also did so and let the planet know how she decide to handle the
kernel compiler issue, if this can let you feel better. :o)
> Finally, if I were to state "fsmlabs are a bunch of pinheads because
> they did XXX" I would expect you to defend your employer as well if I
> misrepresented them due to incorrect statements. Right? :-)
Wrong, as far as it is David S. Miller who is one of the greatest Linux
contributors that made Linux become what it is nowadays, mostly as a free
contributors for years.
I would even accept something like "you caring about your stock-options
not to be victimized by RH7 kgcc blundering", but certainly not that you
just want to blindly defend your employer for corporate reasons.
Regards,
G?rard.
"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 undue pain)
>
> - use IOS C 99 when advantageous
>
> - use GCCisms for the remainder of appropriate things BUT embed them
> in macros defined in header so that they can be systematically
> replaced. Using these macros probably makes the code more readable.
> Use of any GCCism should probably be justified in commentary.
>
> This would improve the code *and* make it more portable.
Why does this improve the code? It gets slower and uglier and more
difficult to maintain.
Why does this make the code more portable? gcc is already highly
portable, and so it the kernel. This too gains us nothing.
Removing gcc-isms without a pragmatic reason -- and no, ISO C compliancy
is not a pragmatic reason -- is silly, extra work for little or no
value.
Jeff
--
Jeff Garzik | Dinner is ready when
Building 1024 | the smoke alarm goes off.
MandrakeSoft | -/usr/games/fortune
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 the
interim the kernel will either move towards supporting both, or a
quantum jump to support the new gcc3+ compiler only. I am hoping a
little thought can get put into this such that this change will be less
painful down the road.
That's reasonable as a long-term goal. Keep in mind that though there
have been questions in the past about code correctness assumptions of
kernel versus specific GCC versions. This has been one place where GCC
has tended to blame the kernel developers, and kernel developers have
pointed out (rightly, in my opinion) that the GCC documentation of some
of these features has been less than stellar --- in fact, some would say
non-existent. If it's not documented, then you don't have much moral
ground to stand upon when people complain that the changes you made
breaks things.
So moving to a C99 syntax is useful simply from the point of view that
it's well documented (unlike the register constraints for inline
functions, which still give me a headache whenever I try to look at the
GCC "documentation"). The problem here is that C99 doesn't (as far as I
know) give us everything we need, so simply moving to C99 syntax won't
be sufficient to support propietary C compilers.
There will also be work needed to make sure that a kernel compiled with
gcc 3.x (whenever it's ready) will actually omit code which was intended
by the kernel developers. So we're definitely looking at a 2.5+
project, and one which may actually be fairly high risk; it's certainly
not a trivial task.
- Ted
Date: Thu, 2 Nov 2000 22:24:27 +0100 (CET)
From: G?rard Roudier <[email protected]>
> Finally, if I were to state "fsmlabs are a bunch of pinheads because
> they did XXX" I would expect you to defend your employer as well if I
> misrepresented them due to incorrect statements. Right? :-)
Wrong, as far as it is David S. Miller who is one of the greatest Linux
contributors that made Linux become what it is nowadays, mostly as a free
contributors for years.
Gerard, please replace "employer" in my words above with "group who
you believe in" (for me, such an example would be the SparcLinux
project) and you will arrive at the true gist of my statements.
I will defend anyone in the Linux community who is being wronged and
who I believe in. It is not a gift specific to the company I work
for. I would bestow it even upon one of my ex-employers, it does not
matter. I don't think I have become as cold blooded as you would make
me out to be :-)
Later,
David S. Miller
[email protected]
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 existing world as
we know it.
Tim
"Theodore Y. Ts'o" wrote:
>
> 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 the
> interim the kernel will either move towards supporting both, or a
> quantum jump to support the new gcc3+ compiler only. I am hoping a
> little thought can get put into this such that this change will be less
> painful down the road.
>
> That's reasonable as a long-term goal. Keep in mind that though there
> have been questions in the past about code correctness assumptions of
> kernel versus specific GCC versions. This has been one place where GCC
> has tended to blame the kernel developers, and kernel developers have
> pointed out (rightly, in my opinion) that the GCC documentation of some
> of these features has been less than stellar --- in fact, some would say
> non-existent. If it's not documented, then you don't have much moral
> ground to stand upon when people complain that the changes you made
> breaks things.
>
> So moving to a C99 syntax is useful simply from the point of view that
> it's well documented (unlike the register constraints for inline
> functions, which still give me a headache whenever I try to look at the
> GCC "documentation"). The problem here is that C99 doesn't (as far as I
> know) give us everything we need, so simply moving to C99 syntax won't
> be sufficient to support propietary C compilers.
>
> There will also be work needed to make sure that a kernel compiled with
> gcc 3.x (whenever it's ready) will actually omit code which was intended
> by the kernel developers. So we're definitely looking at a 2.5+
omit? did you mean emit?
> project, and one which may actually be fairly high risk; it's certainly
> not a trivial task.
>
> - Ted
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
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 been coding C for some years ... But I don't know too much these
features (even don't know about named initializers found in this list
some weeks ago, I don't know only the name of this thing ? ;-)
So where can I read about these ?
Thanx, Gabor
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 we help you make it possible to use a proprietary C
> compiler?
>
> This is right on the money. I hope to show that is is all part of "World
> Domination". ;-) I can easily see other paths to get there though, so
> why this one?
>
> 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 towards supporting both, or a
> quantum jump to support the new gcc3+ compiler only. I am hoping a
No I think that there will be just a switch for gcc along the lines of
gcc --forget-our-extensions-use-c99-for-this-file. Gnu code is common
enough to
justify this. And nothing will change in old code ;-).
It's only recently that the G++ people got around to throw away some
extensions (on the C++ part).
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 developping (I am
a student in cryptography; I gain 30% speed on MD5 code, for instance,
compared to any version of gcc/egcs).
I think that some small parts of the kernel might take advantage of
the better code (/dev/urandom for instance) but, overall, this is not
critical.
However, using two different compilers is a great way to exhibit bugs.
I was told that some of the code in the kernel makes assumptions about
how gcc optimizes code, which on time to time leads to some problems
when a new version of gcc implements a different strategy. I am not
(yet) an optimizer god, therefore I will not comment any further on this
issue; but I think that it is sane practice, if one wants to remain on
the light side of the code (the one that is specified and does not rely
on not-very-well-documented features), to stress-test portability with
different sets of tools.
Anyway, among the points you talked about:
> 1. C++ style comments
Those ones are in C99. All modern compilers know them, or are doomed to
know them in near future since they are a requirement of the standard.
> 7. Macros with variable numbers of arguments
C99 knows them, with the following syntax: the macro is defined with an
ellipsis (...) as last argument, that represents all extra arguments
(possibly none). The arguments are accessed through the identifier
__VA_ARGS__, which contains all of them (with separating commas).
At least gcc-2.95.2 knows this syntax.
If one wants to build a Linux kernel with another compiler, I would
say that the more critical points are:
** inline assembly (must be almost completely rewritten for each new
compiler -- yuck)
** generalized lvalues (the result of a comma operator being a lvalue
if its last operand is a lvalue)
** compound statements (statement blocks inside expressions)
Other features are likely to be implemented in modern compilers, maybe
with a slightly different syntax, that could be adressed through macros,
or an enhanced preprocessing (put some perl script or smart C parser
between cpp and the compiler itself).
All this is only my opinion. But if I were to design a new OS kernel
right now, I would take special care to isolate and document extensions
as much as possible, so that I could ease portability and find bugs more
easily.
--Thomas Pornin
| 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 clue about kernel<->gcc interdependencies and
| issues.
Not a very informative summary. It may be true, but you ought to
help the reader learn. A pointer is welcome.
| > - use ISO C 89 when possible (without undue pain)
| >
| > - use IOS C 99 when advantageous
| >
| > - use GCCisms for the remainder of appropriate things BUT embed them
| > in macros defined in header so that they can be systematically
| > replaced. Using these macros probably makes the code more readable.
| > Use of any GCCism should probably be justified in commentary.
| >
| > This would improve the code *and* make it more portable.
|
| Why does this improve the code?
In any environment, there are things that accidentally work. Porting
the code finds those accidents and forces you to make them
intentionally work.
For example, my compiler is intended to find questionable code. It
finds lots of things that GCC doesn't (or didn't use to -- I haven't
checked recently). A few years ago, I pushed Midnight Commander
through my compiler and fed a number of suggestions back to Miguel.
| It gets slower and uglier and more
| difficult to maintain.
I never asked for slower. If a GCCism is faster, in a way that
matters (and lots of manual optimizations are not worthwhile), then
that is a justification. So my suggestion allows it.
Well-designed macros improve maintainability. They make the code more
readable. And macro expansion happens at compile time, not run time.
| Why does this make the code more portable? gcc is already highly
| portable, and so it the kernel. This too gains us nothing.
The word "portable" has several meanings. Tim clearly would not be
doing this if Lineo didn't think that it would get the kernel
somewhere that GCC didn't go, or at least didn't go as well as some
other compiler.
In the C standard, "maximally portable" is a higher level of language
conformance.
When I use portable, I also mean "avoiding exploitation of arbitrary
characteristics of the particular environment". This kind of
portability increases robustness in the face of change.
w
Even though the vast majority of LINUX systems run on the x86
architecture, don't you think that we've all been enriched by what has
been learned porting to SPARC, Power PC, 68k, Alpha, HPPA, 390, ARM,
etc.?
Similarly, we'd all benefit by the changes suggested by the experience
of porting the kernel to another compiler.
If you think that the kernel is welded to GCC, it really ought to be
called the GNU/LINUX kernel-and-C-compiler :-)
| Removing gcc-isms without a pragmatic reason -- and no, ISO C compliancy
| is not a pragmatic reason -- is silly, extra work for little or no
| value.
Why? Conforming to a standard is a Good Thing. The ISO process of
making a standard is normally more careful, far sighted, and inclusive
than the extensions a particular implementor puts in their compiler.
A standard is a contract between language implementors and users. We
don't have such a contract with GCC.
There are many resources for C programmers that don't cover GCC
extensions. For example, course, books, and the ISO Standard itself.
Oh, and other compilers.
As HPA alluded to, the GCC extensions are not the most exercised parts
of the compiler. They are thus more likely to contain bugs.
Hugh Redelmeier
[email protected] voice: +1 416 482-8253
On Thu, 2 Nov 2000, Andi Kleen wrote:
> On Thu, Nov 02, 2000 at 07:07:12PM +0000, 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 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 fine. If not, if the SGI compiler is GPL'd pillage its sources
and get that code working in gcc. Otherwise, trying to get linux to work
with other C compilers doesn't seem worth the effort.
Aaron
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 that direction without breaking the existing world as
> we know it.
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 compiler that everyone will use
to build the Linux kernel will be gcc, which means that in order to use
any C99 syntax, it first has to be solid in gcc. That means the best way
of introducing such things into the Linux kernel is to *first* get the C99
support solid, reliable, and efficient in gcc, then once a version of gcc
is released with that support, help get Linux compiling with that version
of gcc.
*Then*, when that version of gcc can be made a prerequisite for the
kernel, you can start switching constructs over to the C99 syntax that gcc
supports.
This is obviously a slow and drawn-out process, but in the end the free
software community not only gets a better-documented syntax in the Linux
kernel code that's more likely to be clearly supported and not broken by
gcc in the future, but the broader community also gets a more closely
conforming compiler that supports the latest C features.
<http://gcc.gnu.org/c99status.html> has the current status of the
development versions of gcc. There are a lot of items listed as Broken or
Missing that I'm sure the gcc developers would welcome volunteer help
with.
(Note that there is not and quite likely never will be any standard syntax
for in-line assembly, as the standardization committee considers it to be
outside their scope, so I doubt you'll ever be completely successful. But
I think your goal is one that can reap benefits even when only partially
accomplished.)
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
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 this as a long term goal. I'll put what effort
> > I can into moving that direction without breaking the existing world as
> > we know it.
>
> 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 compiler that everyone will use
> to build the Linux kernel will be gcc, which means that in order to use
> any C99 syntax, it first has to be solid in gcc. That means the best way
> of introducing such things into the Linux kernel is to *first* get the C99
> support solid, reliable, and efficient in gcc, then once a version of gcc
> is released with that support, help get Linux compiling with that version
> of gcc.
>
> *Then*, when that version of gcc can be made a prerequisite for the
> kernel, you can start switching constructs over to the C99 syntax that gcc
> supports.
Hmmmmm. Last month the compiler related thread on the kernel list was the
kernel couldn't move to newer versions of the compiler because the compiler had
changed things (where newer might mean either the latest snapshot de jour, or a
tested/appropriately patched version based off of the snapshots, or even 2.95).
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 release, you must use revision n of the compiler, but
before that release, you must use revision n-1 of the compiler), so you still
have to maintain support for the old GCC way of doing things, in addition to
the C99 way of doing things probably for a year or so.
--
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [email protected] phone: +1 978-486-9304
Non-work: [email protected] fax: +1 978-692-4482
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 compiler that everyone will
>> use to build the Linux kernel will be gcc, which means that in order to
>> use any C99 syntax, it first has to be solid in gcc. That means the
>> best way of introducing such things into the Linux kernel is to *first*
>> get the C99 support solid, reliable, and efficient in gcc, then once a
>> version of gcc is released with that support, help get Linux compiling
>> with that version of gcc.
>> *Then*, when that version of gcc can be made a prerequisite for the
>> kernel, you can start switching constructs over to the C99 syntax that
>> gcc supports.
> Hmmmmm. Last month the compiler related thread on the kernel list was
> the kernel couldn't move to newer versions of the compiler because the
> compiler had changed things (where newer might mean either the latest
> snapshot de jour, or a tested/appropriately patched version based off of
> the snapshots, or even 2.95).
That's why I have the bit above about "help get Linux compiling with that
version of gcc." My understanding is that the Linux core developers want
to support newer versions of gcc as they come out, but that it's a slow
process and relies on volunteers tracking down what's changed in gcc and
updating the kernel to either use coding constructs that work better with
a newer gcc or to use appropriate flags to turn off new gcc features that
don't work well with the kernel (like strict-aliasing).
Clearly people who have a strong interest in being able to use newer
versions of gcc for kernel compiles (such as people who want to
*eventually* be able to use some C99 features) are the best people to help
do this work since they'll be scratching their own itch, so to speak.
> 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).
People may be advocating that, but I think that in my message above, I'm
pretty clearly *not* advocating this. I'm saying that if the goal is to
eventually be able to use C99 syntax in the Linux kernel, the obvious
first step that has to be accomplished before that goal is even remotely
possible is to make sure that the compiler that the kernel uses has good
C99 support. And that achieving this goal has many benefits for the
community as a whole at the same time.
We have to get to point A before we can get to point H. That doesn't mean
that point A leads directly to point H without the intervening B-G. :)
> Note, I seriously doubt Linus will want a flag day (ie, after a given
> kernel release, you must use revision n of the compiler, but before that
> release, you must use revision n-1 of the compiler), so you still have
> to maintain support for the old GCC way of doing things, in addition to
> the C99 way of doing things probably for a year or so.
It depends on the time scale. I don't believe compilers older than 2.7.2
are really supported any more, are they? And I would expect that before
*too* much longer, compilers older than egcs 1.1 won't be supported any
more, since some of the bugs in 2.7.2 are already raising their heads.
With time, the kernel does eventually change its minimum supported gcc
version number. As soon as that minimum supported version number reaches
a version of gcc that supports a C99 feature, that feature can then
reasonably be used in the kernel. It's quite possible, even likely, that
having the C99 feature isn't enough reason to move the minimum supported
version number by itself, but with enough patience it will creep forward
anyway.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
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 the copyright to
said code would have to remain.
>From what I understand the FSF will not allow any code to be added to
gcc that is not copyright by the FSF. Intel has offered direct patches
to gcc to support better optimizations for Itanium. Some of there
patches improve performance on other platforms. As far as I know the gcc
team has not even looked at the patches but has required that full
copyright be transferred to the FSF first.
I understand there are other hardware vendors who have written patches
only to be met by this same adamant position taken by the FSF.
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.
Note: it _is_ clear that this position _could_ be of _some_ benefit to
the Free Software community as it places the FSF in a more defensible
position if there were ever a legal dispute on pirated sections of the
FSF copyrighted code.
Aaron Sethman wrote:
>
> On Thu, 2 Nov 2000, Andi Kleen wrote:
>
> > On Thu, Nov 02, 2000 at 07:07:12PM +0000, 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 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 fine. If not, if the SGI compiler is GPL'd pillage its sources
> and get that code working in gcc. Otherwise, trying to get linux to work
> with other C compilers doesn't seem worth the effort.
>
> Aaron
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
> 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 the copyright to
> said code would have to remain.
Pro64 is free software and Pro64 understands gcc syntax. No problem at all.
[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 will have to be removed at some point. In the
> > interim the kernel will either move towards supporting both, or a
> > quantum jump to support the new gcc3+ compiler only. I am hoping a
> > little thought can get put into this such that this change will be less
> > painful down the road.
>
> BTW: the C99 syntax for named structure initializers is supported from
> gcc 2.7.<something> on. But a policy decision has been take to use
> gcc synta in kernel.
Just so everyone knows what we're talking about, some examples from C99:
33 EXAMPLE 9 Arrays can be initialized to correspond to the elements of an
enumeration by using designators:
enum { member_one, member_two };
const char *nm[] = {
[member_two] = "member two",
[member_one] = "member one",
};
34 EXAMPLE 10 Structure members can be initialized to nonzero values
without depending on their order:
div_t answer = {
.quot = 2,
.rem = -1
};
35 EXAMPLE 11 Designators can be used to provide explicit initialization
when unadorned initializer lists might be misunderstood:
struct { int a[3], b; }
w[] = {
[0].a = {1},
[1].a[0] = 2
};
MfG Kai
[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 integration.
> >
> > I'll keep plugging away at other stuff here as well.
>
> I've been coding C for some years ... But I don't know too much these
> features (even don't know about named initializers found in this list
> some weeks ago, I don't know only the name of this thing ? ;-)
> So where can I read about these ?
In the standard, available for example from ANSI. Someone gave an URL.
Old drafts may be available on the web, but will obviously differ in some
details (and give no indication which details that are).
MfG Kai
[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 include ANSI C++
> style comments.
I don't know about the *next* ANSI C, but the *current* ANSI C is ISO C 99
(ISO/IEC 9899:1999 (E)) and *does* have C++ style comments.
ANSI at least will happily sell you a PDF.
MfG Kai
[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 a hard problem.
Anyone interested in looking at the asm problem, the Free Pascal Compiler
(GPL) seems to be able to read several different Pascal inline asm
variants and translate them into several different output asm variants,
but only for Intel code. That should at least give some hints about the
problem.
MfG Kai
[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 committee had problems using gcc
solutions given that nobody would be able to really describe them.
And the reason no such expert was there was that the FSF didn't send
anyone, because they seem to think standards tend to ignore what they want
to do.
It's a classic vicious circle.
MfG Kai
[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 daily CVS of gcc at work, with an automatic
diff mailed to me, and the amount of daily changes is simply incredible.
Practically no day passes without at least one big pach, and about half a
dozen patches from different people at least, going into the CVS.
I don't know how much faster you can get and still hope to deliver a
stable product at the end.
MfG Kai
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 was nobody on the committee
> who really understood gcc well, so the committee had problems using gcc
> solutions given that nobody would be able to really describe them.
Or the GCC syntax was too limited to do all of what the committee wanted.
> And the reason no such expert was there was that the FSF didn't send
> anyone, because they seem to think standards tend to ignore what they want
> to do.
Actually, RMS had quite a lot of influence on the original standard, even
though he didn't attend the meetings. His replies to the public comment period
were fairly long and real insightful. Even if some of his issues were voted
down, they were discussed over quite a few meetings.
I was on the original ANSI C committee from its founding, through the C89
standard, and for a year or two afterwards as the initial changes for C99 were
discussed, for a total of 10 1/2 years (representing first Data General, then
for OSF, though the early Data General years were before I switched over to
GCC). Towards the end, I was rather burned out by the process, and didn't push
too hard at Cygnus to go to the meetings, and nobody seemed willing to step in
(at the time Cygnus only had 4 GCC engineers, and like now there was always
more GCC work to do than bodies to do work). The trouble is it takes a lot of
time from your paying job to actively participate (figure 4 week long meetings
a year, plus the time to read documents, wordsmith, etc.).
--
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [email protected] phone: +1 978-486-9304
Non-work: [email protected] fax: +1 978-692-4482
[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
> > > 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 committee had problems using gcc
> > solutions given that nobody would be able to really describe them.
>
> Or the GCC syntax was too limited to do all of what the committee wanted.
Well, what I wrote was a paraphrase from what committee members said in
comp.std.c.
> > And the reason no such expert was there was that the FSF didn't send
> > anyone, because they seem to think standards tend to ignore what they want
> > to do.
>
> Actually, RMS had quite a lot of influence on the original standard, even
> though he didn't attend the meetings. His replies to the public comment
> period were fairly long and real insightful. Even if some of his issues
> were voted down, they were discussed over quite a few meetings.
And what I wrote here was another paraphrase - from memory - of what a gcc
guy said on the same group.
Deja will show the context, in case that's not beyond its current event
horizon.
MfG Kai
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:
>
> > 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 the copyright to
> > said code would have to remain.
>
> Pro64 is free software and Pro64 understands gcc syntax. No problem at all.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
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 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.
Jakub
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 from Pro64 over into gcc.
>
> 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.
>
> Jakub
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
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, or SGI would have to be willing to assign some code to FSF.
Which is the standard procedure that the FSF requires for all it's
programs to be able to defend them - incorporating non-assigned code into
gcc creates some intractable problems (i.e.: make it impossible) when the
FSD ever wanted to go to court to defend the freedom of gcc.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [email protected] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
> 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 unable to do ia64 well, pro64 is free software and
both understand the same syntax Im at a bit of a loss why that is productive ?
> 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 anyway
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?
>
> If gcc is architecturally unable to do ia64 well, pro64 is free software and
> both understand the same syntax Im at a bit of a loss why that is productive
Alan Cox wrote in another message:
> Or a third party decides its a silly situation and does it anyway
A definite possibility.
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
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 not and will not happen.
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 created. Presumably then
any defense of gcc code could be met with the argument that the code
used came from sgigcc. This being the case what has the FSD gained by
the current policy?
I suppose that this is even the case today as one could argue that code
came from intel-gcc if they used the Intel patches for ia64 or any other
non-FSF copyrighted patches including patches made by the same company
that the FSD might be in legal action with.
In short, I do not see any enforceable advantages to the current FSF
policies.
> > 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 all it's
> programs to be able to defend them - incorporating non-assigned code into
> gcc creates some intractable problems (i.e.: make it impossible) when the
> FSD ever wanted to go to court to defend the freedom of gcc.
Statements above are my own, and I am not a lawyer.
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
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 all it's
> programs to be able to defend them
... or sell them under a different license. Not that they would, but they
could, if they really wanted to.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
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 other parties. Let's say
> this happens and a new sgigcc source base is created. Presumably then
We recently saw that creating a new, probably incompatible compiler is a
very bad thing. If sgi would split the compiler that would be a problem
for the community at large.
> any defense of gcc code could be met with the argument that the code
> used came from sgigcc
YANAL and IANAL, but to defend code you must own it or have authored it.
Since the FSF would, in your example, neither own the code nor be the
author of it they couldn't defend that version of gcc.
> This being the case what has the FSD gained by
Well, simply this is _not_ the case ;)
> In short, I do not see any enforceable advantages to the current FSF
You don't. Lawyers do (certainly the FSD lawyer does), and probably the
law does, also ;)
> Statements above are my own, and I am not a lawyer.
Yepp.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [email protected] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
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 standard procedure that the FSF requires for all it's
> > programs to be able to defend them
>
> ... or sell them under a different license. Not that they would, but they
> could, if they really wanted to.
The wording of the standard copyright assignment to the FSF binds the
FSF so that it can only release the code under a free software
license.
Eric
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 "intellectual production" cannot give
away this authorship; all he can give is the ability to reproduce,
reuse and redistribute his work.
However, this intellectual property, which is eternal (it does not stop
with the death of the author, and yet may not be transfered to other
people even in such an occurence), is not bound by any scriptural glyph
such as '(c)'. I can add '(c) Free Software Fundation' in all my source
files, and they will remain mine.
So, where I live, the point is moot.
--Thomas Pornin
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 release, you must use revision n of the compiler, but
> before that release, you must use revision n-1 of the compiler), so you still
> have to maintain support for the old GCC way of doing things, in addition to
> the C99 way of doing things probably for a year or so.
The recommended compiler is changing, it is now up to egcs-1.1.2. There is
a long lag, to be sure.
In any case, C99 _will_ come, so it is worthwhile to rewrite gcc-isms that
C99 does differently and egcs-1.1.2 supports *if* it doesn't impose a
penalty of some other sort. The point is that many gcc extensions are
poorly documented and moreover their semantics have changed over time (The
kernel is one of the main users of gcc extensions, other software has to
cater for being compiled with other compilers, and is thus more restricted
here. I'd guess glibc is second here. Little used extensions tend to be
broken or wobbly.). C99 is well documented, but the implementation of its
features might not be solid yet...
Named structure initializers and varargs macros come to mind. The code
should also be checked for possible use of restrict parameters.
--
Dr. Horst H. von Brand mailto:[email protected]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
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 fine. If not, if the SGI compiler is GPL'd pillage its sources
> and get that code working in gcc. Otherwise, trying to get linux to work
> with other C compilers doesn't seem worth the effort.
Pro64 is gcc derived and intended to be 100% source compatible with gcc.
Past experience with new optimizations in gcc is they they frequently
triggered bugs in the kernel source which simply was relying on the code
generation working in a certain way. Given that and assuming that the
degree of Pro64's optimizations is somewhat revolutionary when compared
to gcc I would expect that we'll hit a number of kernel bugs. I'm not
even thinking about actual Pro64 bugs itself.
Ralf
>>>>> "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 your belief, but I would not choose to enforce it on
Tim> everyone. Thank you for you opinion.
Then don't try to enforce proprietary compilers on the kernel
developers either. It's the developers who write the kernel and they
use gcc extensions. There is no reason to cripple the kernel to
satisfy people who wants to use proprietary software to compile it -
not our problem.
Jes
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 feasible, for example. I
am not asking anyone to use a proprietary compiler of they do not choose
to do so.
Jes Sorensen wrote:
>
> >>>>> "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 your belief, but I would not choose to enforce it on
> Tim> everyone. Thank you for you opinion.
>
> Then don't try to enforce proprietary compilers on the kernel
> developers either. It's the developers who write the kernel and they
> use gcc extensions. There is no reason to cripple the kernel to
> satisfy people who wants to use proprietary software to compile it -
> not our problem.
>
> Jes
--
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
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
> the gcc team. We should adopt c99 syntax where feasible, for example. I
> am not asking anyone to use a proprietary compiler of they do not choose
> to do so.
>
But we __do__ use c99 syntax wherever possible. However, not all
of the kernel can be written strictly in 'C'. We need to use some
assembly language for the hardware-specific stuff. Gcc provides
those capabilities. We also need to control the alignment of
some structure members because networking, SCSI, and a few other
links to the outside world count on that. Gcc provides this
capability also. It's a damn good tool.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
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 are done the gcc-only way instead of the c99 way.
nobody is suggesting that the kernel loose functionality to achieve
portability, the suggestion was mearly to be portable where possible and
clearly mark the places where gcc-isms are used and why.
David Lang
On Tue, 7 Nov 2000, Richard B. Johnson wrote:
> Date: Tue, 7 Nov 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 in 2.4.0-test10?)
>
> 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
> > the gcc team. We should adopt c99 syntax where feasible, for example. I
> > am not asking anyone to use a proprietary compiler of they do not choose
> > to do so.
> >
>
> But we __do__ use c99 syntax wherever possible. However, not all
> of the kernel can be written strictly in 'C'. We need to use some
> assembly language for the hardware-specific stuff. Gcc provides
> those capabilities. We also need to control the alignment of
> some structure members because networking, SCSI, and a few other
> links to the outside world count on that. Gcc provides this
> capability also. It's a damn good tool.
>
>
> Cheers,
> Dick Johnson
>
> Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
>
> "Memory is like gasoline. You use it up when you are running. Of
> course you get it all back when you reboot..."; Actual explanation
> obtained from the Micro$oft help desk.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
>
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 are done the gcc-only way instead of the c99 way.
>
> nobody is suggesting that the kernel loose functionality to achieve
> portability, the suggestion was mearly to be portable where possible and
> clearly mark the places where gcc-isms are used and why.
>
> David Lang
Sure, but certain c99 things, like `pragma` tend to be global to
a file so they look like they might work, but then tend to have
other unwanted side effects (pack comes to mind).
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
On Tue, Nov 07, 2000 at 01:52:59PM -0700, Tim Riker wrote:
> 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 feasible, for example. I
> am not asking anyone to use a proprietary compiler of they do not choose
> to do so.
The two problems with your "point" are (1) there is no evidence in its
favor and (2) you have an alternative reason for making such an
argument and by not either making it explicit or explicitly denying
it, you appear to be simply trying to disguise a marketing strategy
in a pseudo-technical argument.
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
http://www.fsmlabs.com http://www.rtlinux.com