<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 16, 2009, at 6:12 PM, Daniel Dunbar wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Tue, Jun 16, 2009 at 1:35 PM, Eli Friedman<<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>> wrote:<br><blockquote type="cite">On Tue, Jun 16, 2009 at 10:57 AM, Tanya Lattner<<a href="mailto:lattner@apple.com">lattner@apple.com</a>> wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Hello! I posted this to llvmdev, but because 2.6 will be the first<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">release including Clang, I thought I should also announce it here.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">At this point, it's probably worth discusssing what we actually want<br></blockquote><blockquote type="cite">to do for a release.<br></blockquote><br>The best we can! :)<br><br><blockquote type="cite">What's the version number? Are we going to call it clang 2.6, clang<br></blockquote><blockquote type="cite">1.0, clang 0.9, or something else? Are we going to call it a preview<br></blockquote><blockquote type="cite">release, or do we think it's stable?<br></blockquote><br>Personally, I vote for 1.0, and I don't know if we need to call it<br>either a preview or stable release. I think its more important to just<br>describe what it does well, whats lacking, and whats known to work /<br>not work.<br><br><blockquote type="cite">What sort of release validation should we do? At a minimum, I think<br></blockquote><blockquote type="cite">we want to make sure clang builds and "make test" passes on all the<br></blockquote><blockquote type="cite">platforms where we do release validation for LLVM. PR4171 is blocking<br></blockquote><blockquote type="cite">this. Beyond that, it would be nice if the C tests in llvm-test<br></blockquote><blockquote type="cite">passed on x86-32/64. Anything else I'm missing?<br></blockquote><br>Certainly having llvm-test pass for x86-32/64 is good, I've cleaned<br>this up a bit lately and I believe that tonight's run will come out<br>all green for clang on i386-darwin-apple9. It would be nice to<br>fix/verify this on linux and freebsd, and I will bring my clang/linux<br>nightly test back online at some point to help. I can also add SPEC to<br>my existing nightly tester (lordcrumb).<br><br></div></blockquote><div><br></div><div>Getting this done by the release is great, but for the first release, we are just establishing a baseline. So this means that clang must build, make check clean, and have results for the test-suite. Not everything has to pass at this point. We just want to know the current state, so that future releases at the bare minimum meet that and hopefully improve. Please note that as of this time, we are dropping ppc support unless someone steps up to qualify it for the release (PR4171 is ppc specific right?)</div><br><blockquote type="cite"><div>Eventually I would like to have a collection of projects that we build<br>which also have decent test suites, so that we also get some<br>reasonable testing of the generated code. Potential candidates here<br>are gcc, Python, glib/gtk, and ... suggestions?<br><br></div></blockquote><div><br></div><div>I think testing clang on a large variety of code is excellent. My concern here is that if these code bases are not regularly tested (ie. by a buildbot/nightly-tester as a part of llvm-test) that the test will only be performed at release times (this happens frequently with llvm releases). Some bugs are easy to fix quickly, and some might require more time and every single bug fix introduces a certain amount of risk. </div><div><br></div><div>If I delayed the release for every bug that gets found, we would never get a release out the door. Thats why we have a decent test suite to use as our "bare minimum". </div><div><br></div><div>Thanks,</div><div>Tanya</div><div><br></div><br><blockquote type="cite"><div><blockquote type="cite">We really need to make sure all of our documentation is in shape;<br></blockquote><blockquote type="cite">being the first LLVM release with clang, it's probably going to<br></blockquote><blockquote type="cite">attract a significant amount of attention. The documentation is<br></blockquote><blockquote type="cite">mostly in reasonably good shape at the moment, but the users manual in<br></blockquote><blockquote type="cite">particular needs work. Updated performance numbers would also be<br></blockquote><blockquote type="cite">nice; the numbers at <a href="http://clang.llvm.org/performance.html">http://clang.llvm.org/performance.html</a> are pretty<br></blockquote><blockquote type="cite">old.<br></blockquote><br>Yes, I will update this soon.<br><br><blockquote type="cite">Are there any particular features/bugfixes that we should try to make<br></blockquote><blockquote type="cite">sure are in the release? From the perspective of "we don't want to<br></blockquote><blockquote type="cite">accept code that gcc accepts, but compile it wrong", PR2461, PR3679,<br></blockquote><blockquote type="cite">PR3811, PR3895, PR4098, and PR4386 are of interest. We should also<br></blockquote><blockquote type="cite">try to figure out the issues with unreduced known miscompiles,<br></blockquote><blockquote type="cite">specifically PR3480 and PR3910. PR4296 and at least parsing for<br></blockquote><blockquote type="cite">PR3429 would be nice because the errors are confusing. (List of all<br></blockquote><blockquote type="cite">those bugs: <a href="http://llvm.org/bugs/buglist.cgi?quicksearch=2461%2C4010%2C3679%2C3811%2C3895%2C4098%2C4386%2C3480%2C3910%2C4296%2C3429">http://llvm.org/bugs/buglist.cgi?quicksearch=2461%2C4010%2C3679%2C3811%2C3895%2C4098%2C4386%2C3480%2C3910%2C4296%2C3429</a><br></blockquote><blockquote type="cite">)<br></blockquote><br>Nice list! I'm not particularly worried about the more esoteric<br>features (nested functions, __label__), but the miscompiles and the<br>calling convention bugs should be high priority.<br><br>My two cents,<br> - Daniel<br><br><blockquote type="cite">-Eli<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">cfe-dev mailing list<br></blockquote><blockquote type="cite"><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br></blockquote><blockquote type="cite"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br></blockquote><blockquote type="cite"><br></blockquote><br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br></div></blockquote></div><br></body></html>