[cfe-dev] LLVM 2.6 release schedule

[Daniel Dunbar]

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

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?

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