[cfe-dev] LLVM 2.6 release schedule

[Tanya Lattner]

On Jun 16, 2009, at 6:12 PM, Daniel Dunbar wrote:

> On Tue, Jun 16, 2009 at 1:35 PM, Eli  
> Friedman<eli.friedman at gmail.com> wrote:
>> On Tue, Jun 16, 2009 at 10:57 AM, Tanya Lattner<lattner at apple.com>  
>> wrote:
>>> Hello! I posted this to llvmdev, but because 2.6 will be the first
>>> release including Clang, I thought I should also announce it here.
>>
>> At this point, it's probably worth discusssing what we actually want
>> to do for a release.
>
> The best we can! :)
>
>> What's the version number?  Are we going to call it clang 2.6, clang
>> 1.0, clang 0.9, or something else?  Are we going to call it a preview
>> release, or do we think it's stable?
>
> Personally, I vote for 1.0, and I don't know if we need to call it
> either a preview or stable release. I think its more important to just
> describe what it does well, whats lacking, and whats known to work /
> not work.
>
>> What sort of release validation should we do?  At a minimum, I think
>> we want to make sure clang builds and "make test" passes on all the
>> platforms where we do release validation for LLVM.  PR4171 is  
>> blocking
>> this.  Beyond that, it would be nice if the C tests in llvm-test
>> passed on x86-32/64.  Anything else I'm missing?
>
> Certainly having llvm-test pass for x86-32/64 is good, I've cleaned
> this up a bit lately and I believe that tonight's run will come out
> all green for clang on i386-darwin-apple9. It would be nice to
> fix/verify this on linux and freebsd, and I will bring my clang/linux
> nightly test back online at some point to help. I can also add SPEC to
> my existing nightly tester (lordcrumb).
>

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?)

> Eventually I would like to have a collection of projects that we build
> which also have decent test suites, so that we also get some
> reasonable testing of the generated code. Potential candidates here
> are gcc, Python, glib/gtk, and ... suggestions?
>

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.

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".

Thanks,
Tanya


>> We really need to make sure all of our documentation is in shape;
>> being the first LLVM release with clang, it's probably going to
>> attract a significant amount of attention.  The documentation is
>> mostly in reasonably good shape at the moment, but the users manual  
>> in
>> particular needs work. Updated performance numbers would also be
>> nice; the numbers at http://clang.llvm.org/performance.html are  
>> pretty
>> old.
>
> Yes, I will update this soon.
>
>> Are there any particular features/bugfixes that we should try to make
>> sure are in the release? From the perspective of "we don't want to
>> accept code that gcc accepts, but compile it wrong", PR2461, PR3679,
>> PR3811, PR3895, PR4098, and PR4386 are of interest.  We should also
>> try to figure out the issues with unreduced known miscompiles,
>> specifically PR3480 and PR3910.  PR4296 and at least parsing for
>> PR3429 would be nice because the errors are confusing.  (List of all
>> those bugs: http://llvm.org/bugs/buglist.cgi?quicksearch=2461%2C4010%2C3679%2C3811%2C3895%2C4098%2C4386%2C3480%2C3910%2C4296%2C3429
>> )
>
> Nice list! I'm not particularly worried about the more esoteric
> features (nested functions, __label__), but the miscompiles and the
> calling convention bugs should be high priority.
>
> My two cents,
> - Daniel
>
>> -Eli
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20090617/8ef485ec/attachment.html>