<div>Thank you.</div>
<div>I'll take all these valuable facts in to consideration and come up with my proposal for </div>
<div>this project .</div>
<div> </div>
<div>Kumaripaba</div>
<div><br> </div>
<div><span class="gmail_quote">On 3/30/08, <b class="gmail_sendername">Török Edwin</b> <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:edwintorok@gmail.com" target="_blank">edwintorok@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Chris Lattner wrote:<br>><br>> On Mar 29, 2008, at 11:53 PM, Kumaripaba Miyurusara Atukorala wrote:<br>
><br>>> hi,<br>>> This e-mail is written to involve some of the project ideas in LLVM<br>>> in GSOC this year.<br>>> I was looking in to the ideas mentioned under improving current<br>>> system and found the idea of "Compile programs with the LLVM<br>
>> Compiler" to be interesting. I would like to compile one of the large<br>>> code bases that have not yet been compiled with LLVM and convert the<br>>> build system to be compatible with the LLVM Programs testsuite.<br>
>><br>>><br>>><br>>> But I have several doubts to be clarified. They are listed below.<br>>><br>>> * I would like to know whether this is a suitable project for GSOC?<br>>> * What software has already been compiled with LLVM and what are<br>
>> not; so that I can identify the possible candidates for the<br>>> project?<br>>><br>> I think this would be a great project. However, I would rephrase it<br>> to be more concrete.<br>
><br>> How about taking a linux distro like redhat or gentoo or whatever you<br>> are familiar of comfortable with, and try compiling the whole thing<br>> with llvm-gcc? As part of the GSoC project, you could file bug<br>
> reports for any issues you hit and help track down problems.<br>><br><br>Excellent idea!<br><br>When testing large code bases built with llvm, and trying to track down<br>where the problem is it would be very useful to have an automated tool<br>
to help. Something similar to 'git bisect', or bugpoint but for many<br>source files.<br><br>For example: built entire code with gcc, get some "expected output" (run<br>make check, ....), same for llvm-gcc. If they differ, start tracking<br>
down (automatically!) in which source files the problem is. Then you<br>build half code with llvm, half with gcc. If it breaks, you build 1/4<br>llvm, 3/4 gcc; if it doesn't break you build 3/4 llvm, 1/4 gcc, and so<br>
on. The situation should be logged by a tool, because for example I<br>would certainly forget which build worked, and which one didn't.<br>It would make sense to cache files previously built, an easy way to do<br>that would be to build everything with one compiler, then backup&remove<br>
one half, and built it with the other compiler (just run make with the<br>correct compiler, it will rebuild the missing files). Then restore the<br>half, remove a quarter, repeat.<br><br>If this tool could be a drop-in wrapper for CC/CXX, it would be<br>
excellent, since nearly every autotooled package could be tested this way.<br><br>P.S.: to avoid duplicate bug reports, I think filing a "meta" bug that<br>holds as depedencies all bugs that affect package X would be useful.<br>
<br>Best regards,<br>--Edwin<br>_______________________________________________<br>LLVM Developers mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></div><br>