Where did kgcc go in 2.4.0-test10 ?

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]

-
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/

I've not yet submitted it to Linus is the obvious reason 8)

Alan

-
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/

The global Makefile in 2.4.x -never- looked for kgcc.

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
-
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/

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]

-
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/

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.

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
-
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/

I haven't submitted it. Im happy to do so if people want it in.

-
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/

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.)
-
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/

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]
-
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/

and conectiva

-
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/

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
-
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/

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.

-
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/

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.)

-
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/

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.

-
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/

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]>

-
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/

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)$ 
-
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/

From: Ben Pfaff <[email protected]>
Date: 01 Nov 2000 18:07:53 -0500

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]
-
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/

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/
-
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/

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

-
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/

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
-
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/

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

-
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/

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
-
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/

heh, ok. i'm wrong. :)

Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
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/

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/
-
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/

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]
-
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/

} 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.

-
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/

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]
-
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/

Every software seems to be buggy and gcc does not seem to be better than the kernel in this area.

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)

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.

-
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/

Date: Thu, 2 Nov 2000 22:24:27 +0100 (CET)
From: G�rard Roudier <[email protected]>

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]

-
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/

} before on this list) and we didn't have time to implement and QA the

Oh, my.
-
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/

Doing the QA on a kernel change of compiler is a long hard process. It took until 2.2.17 to apparently get a 2.2 kernel solid with gcc 2.95.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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/
-
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/

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]
-
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/

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

-
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/

In article <[email protected]>,

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.
-
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/

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/
-
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/

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]
-
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/

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
-
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/

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/
-
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/

<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
-
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/

Followup to:  <[email protected]>
By author:    "David S. Miller" <[email protected]>
In newsgroup: linux.dev.kernel

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
-
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/

There was already some userland package named kcc, with a kcc binary. A Kanji converter of some sort, IIRC.

Bill
-
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/

According to Jeff Garzik:

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.
-
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/

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.

...

Sometimes one just keeps quiet, and that's o.k.

      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       [email protected] |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |
-
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/

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).

Yes, it fixes several problems the older compilers suffered from, see Richard Henderson's posting about this on lkml from end of September.

Jakub
-
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/

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?

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.
-
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/

I think we only care about this when they become free software.

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

-
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/

This may be your belief, but I would not choose to enforce it on everyone. Thank you for you opinion.

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?

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.
-
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/

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

-
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/

Alan,

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.

I have not looked at this project. Thank you for the pointer. I hope to learn form their experiences.

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.
-
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/

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

-
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/

[email protected] (Alan Cox) wrote on 02.11.00 in <[email protected]>:

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
-
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/

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
-
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/

#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.

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.
-
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/

When you assume C99 it is no problem, because C99 has _Pragma()

-Andi

-
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/

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... ;-)

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.
-
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/

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
-
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/

[email protected] (Gábor Lénárt) wrote on 03.11.00 in <[email protected]>:

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
-
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/

No need to be so flip about it. I believe that most of us feel that way.

-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/

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.

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.
-
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/

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
-
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/

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?

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.
-
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/

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.
-
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/

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.

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.
-
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/

[email protected] (Christoph Hellwig) wrote on 02.11.00 in <[email protected]>:

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
-
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/

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
-
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/

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

omit? did you mean emit?

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.
-
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/

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).
-
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> 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
-
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/

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.

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.
-
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/

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/

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

-
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/

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.

-
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/

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.
 www.fsmlabs.com  www.rtlinux.com

-
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/

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
-
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/

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

-
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/

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.

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.

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.
-
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/

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/

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

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.
-
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/

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 ? -
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/

Alan Cox wrote in another message:

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.
-
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/

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
-
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/

Or a third party decides its a silly situation and does it anyway -
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/

yes, exactly what my comments stated.

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.
-
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/

Which can not and will not happen.

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                       |
                                                         |
-
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/

... 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.
-
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/

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
-
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/

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.

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.
-
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/

In article <[email protected]> you write:

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
-
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/

As I explained three lines below the mail, if you care to read.

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.

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.

Well, simply this is _not_ the case ;)

You don't. Lawyers do (certainly the FSD lawyer does), and probably the law does, also ;)

Yepp.

      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       [email protected] |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |
-
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/

[email protected] (Tim Riker) wrote on 04.11.00 in <[email protected]>:

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
-
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/

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
-
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/

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.
-
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/

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
-
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/

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.
-
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/

| 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.

-
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/

Summary: You have no clue about kernel<->gcc interdependencies and issues.

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
-
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/

| 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

-
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/

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
-
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/

In article <[email protected]> you write:

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:

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.

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
-
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/

[email protected] (Tim Riker) wrote on 02.11.00 in <[email protected]>:

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
-
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/

Or the GCC syntax was too limited to do all of what the committee wanted.

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
-
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/

[email protected] (Michael Meissner) wrote on 04.11.00 in <[email protected]>:

Well, what I wrote was a paraphrase from what committee members said in comp.std.c.

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
-
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/

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.

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/

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)

-
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/

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.
-
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/

[email protected] (Andi Kleen) wrote on 02.11.00 in <[email protected]>:

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
-
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/