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.
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?
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?
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.
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
)
-Eli
> 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.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?
whatever.... given how close clang is to llvm I'd go with 2.6, it also
gives some feeling of maturity 
What sort of release validation should we do? At a minimum, I think
I'd like to see clang compiling > 95% of freebsd ports. We are about
to have another ports build run so we'll see how we stand. we'll keep
you informed...
roman
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.
Sounds good, just MHO:
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?
I think we should call it 1.0 or 2.6. I consider Clang to be quite stable for C/ObjC, but not perfect. Calling it a 1.0 release sends the right message, but calling it 2.6 would also make sense to me.
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?
Our official policy for llvm.org releases is more about regressions than quality. As clang hackers we want to make it as good as possible, but the first release is about setting a baseline.
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 they are. Daniel, can you please update the perf numbers? I can send you my slides if you want.
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: Bug List
)
I think we should aim to fix as many of these as possible, but that if the release comes up and we haven't fixed them all that we should ship anyway with LLVM 2.6 anyway.
-Chris
95% is a really high barrier in my opinion. Last time we were only able
to build 36%.
iirc we did ~90% of those actually built.... and the distribution is gaussian
there are ~5 bugs that will fix most of the ports... I am a firm believer
in 95%
You know that some of those bugs actually prevent us from building 1000
ports at once? Even though it wasn't a bug in Clang, before I patched
libiconv to build with C89, it blocked 9600 packages. A more realistic
scenario was Jasper, which blocked only 2500 packages or so.
Building stuff like Python, Perl and Ruby still seems to be a little
hard now and then.
That's all I meant; it's just that there are a lot of bugs filed
against clang at the moment, and those are ones which shouldn't be
lost in the noise.
-Eli
That would definitely be nice, but it's not going to delay the release.
-Eli
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: Bug List
)
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
ffmpeg would be nice to include: it has a lot of tricky inline asm
constructs and a bunch of tests in "make test". There are some recent
results for compiling ffmpeg with clang at
FATE Server .
-Eli
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?
PHP, for sure.
It has a huge test suite (around 10k tests), and with a high code coverage.
Currently it crashes because of __attribute__ ((noreturn)) in a function parameter · Issue #2833 · llvm/llvm-project · GitHub though. This happens because PHP sets the call convention in some function pointers, which is ignored by clang (although the functions were compiled with fastcall). Thus there's a mismatch in the call conventions across the generated code.
Nuno
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
PR4171 affects any big-endian architecture.
-Eli