plans about kernel compilation?

I'm just a newbie lurker here, but I expect that, in time, you should
be able to compile any kernel that can be compiled with GCC because
one of the goals of the clang project is GCC compatibility.

Ok,maybe I should have been more explicit about what I meant.
Look here for example:
http://gcc.gnu.org/ml/gcc/2007-10/msg00266.html
http://gcc.gnu.org/ml/gcc/2007-10/msg00275.html

There you can find a discusson about a problem for threaded programs caused by a recently made default optimization of gcc. This problem has been discussed on the lkml, because it affects the kernel too. This is a problem more centered on the optimization phase,but if the front-end doesn't care about certain compilation scenarios,maybe the rest of the compiler doesn't care too.So maybe my question hould have been : "Is cfe interested in supporting kernels compilation"?

That *was* your question. Based on the above, it probably should
have been "Is cfe planning on implementing optimizations that cause
memory locations to be written to even if the condition controlling
the write is false (or more generally, optimizations that are hostile
to significant amounts of existing threaded code), with no option to
disable them, and with no alternative less sucky than volatile or
inline assembly?".

-Scott

I'm just a newbie lurker here, but I expect that, in time, you should
be able to compile any kernel that can be compiled with GCC because
one of the goals of the clang project is GCC compatibility.

Yep, absolutely. We should be able to compile the linux kernel in due time. That said, we're implementing C/GCC features on an as-needed basis. If the linux kernel depends on some feature that isn't a high priority for a current contributor, it may be awhile before it is possible. The obvious answer for that is to have more contributors ;-). In any case, clang far enough along for this to be interesting yet.

On the other hand, if you're asking whether "llvm" can compile the kernel, llvm-gcc is probably either capable of doing it now, or very close to being able to. I'd give it a try and file bugs if something doesn't work.

Ok,maybe I should have been more explicit about what I meant.
Look here for example:
Tomash Brechko - Optimization of conditional access to globals: thread-unsafe?
Tomash Brechko - Re: Optimization of conditional access to globals: thread-unsafe?

There you can find a discusson about a problem for threaded
programs caused by a recently made default optimization of gcc.
This problem has been discussed on the lkml, because it affects the
kernel too. This is a problem more centered on the optimization
phase,but if the front-end doesn't care about certain compilation
scenarios,maybe the rest of the compiler doesn't care too.So maybe
my question hould have been : "Is cfe interested in supporting
kernels compilation"?

That *was* your question. Based on the above, it probably should
have been "Is cfe planning on implementing optimizations that cause
memory locations to be written to even if the condition controlling
the write is false (or more generally, optimizations that are hostile
to significant amounts of existing threaded code), with no option to
disable them, and with no alternative less sucky than volatile or
inline assembly?".

Yep, this is a completely different question :). Specifically, this is an optimizer issue, not a front-end issue. If LLVM suffers from the same or similar problems, file a bug and we'll fix it. LLVM tends to be very pragmatic about not gratuitously breaking user code even if the code isn't "strictly standards compliant".

-Chris

I am compiling a 2.6.24-rc1 kernel for x86-64.
I filed 2 bugs for llvm-gcc and clang.

--Edwin

<snip>

"Is cfe planning on implementing optimizations that cause
memory locations to be written to even if the condition controlling
the write is false (or more generally, optimizations that are hostile
to significant amounts of existing threaded code), with no option to
disable them, and with no alternative less sucky than volatile or
inline assembly?".

People interested in the more general issue of proper concurrency support (which subsumes this specific issue of hostile optimizations) might want to look at the proposals (N2429 and N2427) for a multi-threaded memory model and atomic operations for C++1x (which the ISO C++ committee formally adopted earlier this month).

For background information, see the multiple instances of "memory model" and "atomic" in this page:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2389.html

...and give yourself several weeks to digest it all. (:

Note, N2429 and N2427 will be publicly visible when the next WG21 mailing is released (any day now), at which time you can grab them from here:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/

That mailing will also include an updated version of the Working Draft of the next C++ Standard, and it will have the proposed wording from N2429 and N2427 merged in (with LaTeX-diff-o-vision!).

James Widman

I fixed the llvm-gcc bugs.

I closed one clang bug as a dup of the other. I fixed many minor clang bugs in various subsystems exposed by this, thanks!

Unfortunately, I don't have time at the moment to fix the rest of the issues. Here is what is left:

1) Sema::MergeFunctionDecl needs to allow a prototype after a function body.
http://llvm.org/bugs/show_bug.cgi?id=1750#c5

2) GCC anonymous unions parse bug don't allow field access when you use P->b.
http://llvm.org/bugs/show_bug.cgi?id=1750#c6

3) We have a minor sema bug related to struct assignment and cv qualifiers, I asked Steve to investigate:
http://llvm.org/bugs/show_bug.cgi?id=1750#c8

If anyone is interested in tackling #1 or #2, they are both self-contained and would be a great way to dive into clang.

Thanks Edvin!

-Chris