[cfe-dev] plans about kernel compilation?

[Chris Lattner]

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