There have been briefly existent gcc forks in the past, specifically for kernel compilation on various distros.

I suspect there probably will come a time when gcc is replaced. Possibly by an LLVM compiler like clang. But, the likelihood of a from-scratch C compiler just for the kernel seems very low, to me. Yes, the kernel developers could do it. And, yes, Ingo is one of the most productive developers in the world, and if he got it into his head to make such a thing happen (despite the general mood of the community being against such an idea), he could probably do a large percentage of it on his own. But, it's just a very large undertaking, and the things that we all find irritating about gcc are often the things that make it suitable for so many situations and architectures (edge cases are ugly but necessary when talking about supporting huge numbers of architectures).

If they're going to write their own compiler/linker/assembler suite, why even bother remaining compatible with C? Why not just create a specifically-optimized "kernel-ese" DSL?

But that's what C is.

edit: my argument can be summarized in sections 1 and 2 in an essay I wrote for a class a year ago: http://people.cs.vt.edu/~scschnei/ece5530/languages.pdf

OTOH several other OS projects have their own DSLs: Oberon, Vault, BitC, and Sing#.

I think we're abusing the title "Domain Specific Language." I'm only familiar with BitC and Sing# on that list, but I call those systems programming languages. Granted, one could consider systems programming the domain, but since systems programming is so ubiquitous in computing and for a long time that was the only kind of programming, I think it's inaccurate to call those DSLs.

Anyway, with the exception of Oberon, the others are still research projects. I don't think a research language is appropriate for implementing the Linux kernel.

I do hope that in the future, something as important as the Linux kernel is implemented with a modern systems programming language - it would indicate progress - but Linux is an immediate need.

Well, actually if you follow the comment thread - it's not really likely. Most folk are clamoring about how poor an idea this is.

It's worth noting that Clang is being primarily used with the Mach kernel which is heavily influenced by BSD. I don't know enough of the specifics to say whether or not this would make compiling FreBSD easier than the Linux kernel, but I suspect it might.

Actually, Mach and BSD have bupkis in common. It simply so happens that OS X uses a reasonable amount of BSD user-land code in OS X to make compatibility easier. This probably makes porting FreeBSD to clang easier indirectly--the user-land tools and libraries from the BSDs are written in the same style as the kernel, and so supporting them likely makes supporting the kernel easier that much easier--but saying Mach is similar to BSD is like saying Windows NT is similar to DOS simply because it can run DOS programs.

You're technically correct in regards to Mach, but in the context of Mac OS X a very large percentage of the kernel is composed of BSD-derived code.

Unfortunately, none of this is particularly relevant to clang, as the kernel design (in respect to Mach or BSD) really has little bearing on its compiliability.

[Edit]

I'm very surprised that this was downvoted to 0. The discussion was in context of Mac OS X, and the technical veracity is easily confirmed:

http://en.wikipedia.org/wiki/Xnu http://fxr.watson.org/fxr/source/bsd/?v=xnu-1228

Whatever the case, it would be significantly easier to correct GCC's shortcomings instead of starting afresh (and facing all those shortcomings, and others, again).

Have you ever looked at the source of GCC? :-)

I remember coding together a compiler using flex and bison. It was a nightmare. This definitely is not a short term task. Frankly I don't think the commitment is there from the community. Not yet at least.

Then again, gcc breakage is ridiculously common. It's got to be tackled at some point.

Flex and bison? See, that's a mistake right there! The tools often end up more hassle than coding the lexer and parser directly.

Writing compilers is normally fun, not a nightmare. It does tend towards nightmarish if your implementation language is very low-level, though; particularly if it lacks type safety and garbage collection.