Sylvestre's blog

After setting an automatic code coverage tool, I just plugged an automatic scan-build on the LLVM toolchain trunk:

http://buildd-clang.debian.net/scan-build/

Note that:

• polly is currently not analyzed. I had to disable the build until the new version of cloog is available.

• compiler-rt is not analyzed because it does not respect the CC/CXX argument to use the clang built locally [1]. Not sure it is a bug here.

This work is done through the Debian/LLVM jenkins instance.
The report is updated twice a day.
The scan-build/clang used to produce the report is the one published on http://llvm.org/apt/. That means that a new feature/fix done on scan-build will appear only about a day after on report. As a side effect, it tests automatically the packages distributed on llvm.org/apt/.

For a project of this size, the number of reported errors / warnings is pretty low. At time of writing, only 329 errors are reported and many of them are in generated code (AttrDump.inc and LLDBWrapPython.cpp for example) or in unit tests.

[1]
/tmp/buildd/llvm-toolchain-snapshot-3.4~svn185728/build-llvm/Release/bin/clang -fno-exceptions -fPIC -funwind-tables -I/tmp/buildd/llvm-toolchain-snapshot-3.4~svn185728/projects/compiler-rt/lib -I/tmp/buildd/llvm-toolchain-snapshot-3.4~svn185728/projects/compiler-rt/include -Wall -Werror -O3 -fomit-frame-pointer -m64 -fPIE -fno-builtin -gline-tables-only -fno-rtti -DASAN_FLEXIBLE_MAPPING_AND_OFFSET=1 -c -o /tmp/buildd/llvm-toolchain-snapshot-3.4~svn185728/build-llvm/tools/clang/runtime/compiler-rt/clang_linux/asan-x86_64/x86_64/SubDir.lib__sanitizer_common/sanitizer_symbolizer_itanium.o /tmp/buildd/llvm-toolchain-snapshot-3.4~svn185728/projects/compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_itanium.cc

A week after the Euro LLVM conference, I am glad to share the results I presented and discussed during the event.

1) Parallel building infrastructure using clang instead of gcc

Based on the work that Alexander Pashaliyski and I did during the GSoC 2012, we are now able to automatically rebuild each package uploaded in Unstable transparently. Results are published here:
http://buildd-clang.debian.net/
This provides a quick and easy way to any Debian contributors or upstream packaged in Debian to check how the package behaves with clang.
For Debian Developer and maintainer, a per maintainer view is also provided. This will list all packages maintained by a Debian packager. My page as example

Here is an example of the list of package:

And an example of package failing:

At time of writing, most of the packages in unstable have been rebuilt (16 % are remaining). However, due to resource constraints, only amd64 packages are built. Contact me if you have resources to share for other architectures.

Thanks to Paul Wise, the PTS (Debian package tracking system) proposes a link to the clang build logs (failing or not).

A repository will be automatically updated with the results of these builds (once I find the time to get into buildd).

2) clang-built repository
Thanks to the Amazon Cloud, with our new DPL (Debian Project Leader), Lucas Nussbaum, we rebuilt unstable last April and published it at the following address:

deb http://clang.debian.net/repository-2013-04-07/ unstable-clang main

This allows some cool stuff like:

$ echo "deb http://clang.debian.net/repository-2013-04-07/ unstable-clang main">>/etc/apt/sources.list
$ apt-get update
$ apt-get install coreutils/unstable-clang
$ ls
$ awk

Note that this repository was only one-shoot and does not get updated.

Quality of the binary produced (performance and size) can be tested thanks to this repository. Feedbacks are welcome!

After the Debian new packages, removal and bugs feeds (see the previous blog posts), I also plugged a feed with the last uploads in the archive:
Debian uploads on Identi.ca
Debian uploads on Twitter

As a reminder, here is the list.
For identi.ca:
Debian uploads
Debian NEW queue
Debian bugs
Debian removed packages

For Twitter:
Debian uploads
Debian NEW queue
Debian bugs
Debian removed packages

Lately, I have been working on providing nightly packages of the whole LLVM toolchain.
With the help of folks from Intel, Google and Apple, I am happy to announce the publication of these packages:
http://llvm.org/apt/

Built through a Jenkins instance (http://llvm-jenkins.debian.net/), packages for Debian wheezy and Unstable and Ubuntu quantal, precise and raring are created twice a day.

3.2 and 3.3 llvm-toolchain packages are currently waiting in the Debian NEW queue.

More information on the LLVM blog.

After the studies of the rebuild of the Debian archive using clang 2.9 & 3.0 and 3.1, the results of the 3.2 rebuild have been published on http://clang.debian.net.

The percentage of failure is the same as clang 3.1: 12.1% of failure. That means that on 18264 packages, 2204 failed to be built with clang (it was 17710/2137 with the version 3.1).

The fact that the percentage is the same can be explained by at least two reasons:
First, some upstreams packages have been fixed to be built correctly with clang.
Second, the new warnings + -Werror (example: -Wsometimes-uninitialized) introduced in clang 3.2 triggered some new build failures.

To conclude, I think that the 3.2 release confirms the turning point of the 3.1. In term of support of the C and C++ standard, clang has now reached an equivalent quality to gcc (with better detection of errors and an extended set of warnings in -Wall).
Now, from the perspective of the Debian rebuilds, the decrease of number of failures will come from the upstream developers improving their codes (exemple of the error non-void function should return a value) or the Debian Developer/maintainer fixing the programming errors.