On Oct 28, 2007, at 9:30 AM, Scott Wood wrote: > On Sun, Oct 28, 2007 at 12:18:26AM -0700, Giangiacomo Mariotti wrote: >>> 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: >> 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?". 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 _______________________________________________ cfe-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
