[Announcement] 3.3 Release Planning!

Happy April!

[Contrary to the day, this is not an April Fool’s joke. ;-)]

It has been several months since the release of Clang 3.2. Now is the time to start thinking about the next release! The (very) tentative schedule is testing in May and a release in June.

What This Means For You

Now is the time to start thinking about which features you are currently working on and getting them wrapped up. As usual, we will be cutting our branch near the beginning of May. At that point, all new features should be mostly complete. Any patches accepted after we branch must be only of a clean-up or bug fix nature.

Supported Platforms & A Call For Testers

This is also the time to start thinking about which platforms we want to support. We currently support the following platforms:

• MacOS X (x86)
• Linux (Ubuntu - x86)
• FreeBSD (x86)
• Windows (experimentally)

We would like to support ARM again. Also, there has been significant improvements on other platforms. The only thing keeping us from releasing binaries for non-Intel platforms is a phalanx of testers for those platforms. The more testers we have, the better.

Because LLVM is an open source project, we rely upon the community members’ copious spare time to help us push the release out. Not only do we need testers for new platforms, we also need testers for platforms we currently support. Please email me directly if you are interested in becoming a tester.

What does it take to be a tester? I’m glad you asked! You are volunteering your time and resources to test each release candidate. You are given a week to compile the release candidate in a bootstrap build (a script is provided). You then have to run the regression tests and the full test suite, and compare the results from the test suite run to those of the previous release. Any regressions need to be reported as quickly as possible so that people can fix them. You then send the binaries to me so that I can post them for external developers. Rinse. Repeat.

There are normally two rounds of testing. If something major comes up during the second round of testing, we will need a third round. But we try to avoid that as much as possible.

The last step is to package up the binaries so that they can be uploaded to the llvm.org website.

And that’s it!

As May approaches, I’ll send out a more solidified schedule for the release. I’ll also begin warning people of the impending doom^H^H^H^Hbranching.

Cheers!!
-bw

Let's add NetBSD(x86) to that list at least :slight_smile:

The biggest problem I see right now is that we had a number of VM usage
regressions since 3.2. I am running pkgsrc bulk builds with Clang as
compiler and an address space limit of 2GB. A number of new failures
started to pop up recently. I can extract the specific failures, if
there is interest.

Joerg

Question:

Has there ever been a resolution to the impasse between clang's developers and the gnu standard library's developers over the use of '__blocks' as a parameter name in certain headers in their standard lib?

A I recall, they were being asked to change '__blocks' and were in turn wanting clang implement a feature to patch problematic header files and handle the problem itself.

Hi Bill,

Glad you asked! :wink:

I'm getting the test-suite bot green (a few minor tweaks and we're good)
and that should get us well ahead of what we've ever been on ARM. Though,
bootstrapping seem to fails a few check-all tests. I'll look into that as
soon as the test-suite bot is fully green.

Just to make sure we're talking about the same things, the requirements for
release are:

* Green direct check-all (clang-native-arm-cortex-a9 bot, green)
* Green direct test-suite (clang-native-arm-lnt bot, almost green)
* Green self-host check-all (no bot yet, some failures, will look into it
next)
* Green self-host test-suite?
* Anything else?

I don't want to have this for release-only, but as continuous integration.
Though, I hope it'll be good for all future releases.

It's probably best to produce the binaries on a Cortex-A9 (Panda ES), since
they're the most common target and the binaries work quite well on A15s.

Sylvestre,

If we do end up creating ARM binaries for the general public, your input
and expertise will be greatly appreciated! :wink:

cheers,
--renato

• MacOS X (x86)
• Linux (Ubuntu - x86)
• FreeBSD (x86)
• Windows (experimentally)

We would like to support ARM again. Also, there has been significant improvements on other platforms. The only thing keeping us from releasing binaries for non-Intel platforms is a phalanx of testers for those platforms. The more testers we have, the better.

We are currently in the process of switching FreeBSD/ARM over to clang. We will certainly do testing, but I'm not sure it's worth LLVM shipping binaries, as clang 3.3 will be the system compiler and clang trunk is available in ports.

We'd also like to switch MIPS and PowerPC soon, but I believe there are still some minor issues with PowerPC and more significant ones in MIPS, so that's probably more in the 3.4 timeframe.

It's probably best to produce the binaries on a Cortex-A9 (Panda ES), since they're the most common target and the binaries work quite well on A15s.

We still support Cortex-A8 platforms, and one of the most widely deployed ARM platforms for us at the moment is the Raspberry Pi, which is ARM11. I have one sitting on my desk doing nothing at the moment, which could probably be hooked up to the network and used for LLVM builds, although a clean build will probably take about 24 hours on it.

David

    We would like to support ARM again.

Hi Bill,

Glad you asked! :wink:

[...]

Sylvestre,

If we do end up creating ARM binaries for the general public, your input
and expertise will be greatly appreciated! :wink:

I will be happy to provide some Debian & Ubuntu ARM packages. I just
need access to ARM server(s).

Thanks,
Sylvestre

We would like to support ARM again.

Hi Bill,

Glad you asked! :wink:

I'm getting the test-suite bot green (a few minor tweaks and we're good) and that should get us well ahead of what we've ever been on ARM. Though, bootstrapping seem to fails a few check-all tests. I'll look into that as soon as the test-suite bot is fully green.

Just to make sure we're talking about the same things, the requirements for release are:

* Green direct check-all (clang-native-arm-cortex-a9 bot, green)
* Green direct test-suite (clang-native-arm-lnt bot, almost green)
* Green self-host check-all (no bot yet, some failures, will look into it next)

All of this, yes. :slight_smile:

* Green self-host test-suite?

This would be nice.

* Anything else?

The above are pretty much the requirements for other binaries. Of course, I expect (hope?) that the community will take each release candidate and test their own code with it.

I don't want to have this for release-only, but as continuous integration. Though, I hope it'll be good for all future releases.

I do too. The progress you're making is great!

It's probably best to produce the binaries on a Cortex-A9 (Panda ES), since they're the most common target and the binaries work quite well on A15s.

I agree. Though I'll also let Jim and Evan chime in on what they think.

Thank you!
-bw

Sylvestre,

If we do end up creating ARM binaries for the general public, your input and expertise will be greatly appreciated! :wink:

+1 :slight_smile:

We would like to support ARM again.

Hi Bill,

Glad you asked! :wink:

I’m getting the test-suite bot green (a few minor tweaks and we’re good) and that should get us well ahead of what we’ve ever been on ARM. Though, bootstrapping seem to fails a few check-all tests. I’ll look into that as soon as the test-suite bot is fully green.

Just to make sure we’re talking about the same things, the requirements for release are:

  • Green direct check-all (clang-native-arm-cortex-a9 bot, green)
  • Green direct test-suite (clang-native-arm-lnt bot, almost green)
  • Green self-host check-all (no bot yet, some failures, will look into it next)

All of this, yes. :slight_smile:

  • Green self-host test-suite?

This would be nice.

  • Anything else?

The above are pretty much the requirements for other binaries. Of course, I expect (hope?) that the community will take each release candidate and test their own code with it.

I don’t want to have this for release-only, but as continuous integration. Though, I hope it’ll be good for all future releases.

I do too. The progress you’re making is great!

It’s probably best to produce the binaries on a Cortex-A9 (Panda ES), since they’re the most common target and the binaries work quite well on A15s.

I agree. Though I’ll also let Jim and Evan chime in on what they think.

cortex-a9 sounds fine. It’d be cool if we verified those binaries run on a cortex-a8 and a cortex-a15, too. It’d be very, very strange if they didn’t, but hey, catching very, very strange problems is what release testing is for, right? :slight_smile:

At least for now, I do think we should constrain “ARM is a supported target” to mean armv7. For purposes of testing, armv6 is effectively a different target.

-Jim

  • Green direct check-all (clang-native-arm-cortex-a9 bot, green)
  • Green direct test-suite (clang-native-arm-lnt bot, almost green)
  • Green self-host check-all (no bot yet, some failures, will look into it next)

All of this, yes. :slight_smile:

Great! This is feasible for the 3.3 time frame.

  • Green self-host test-suite?

This would be nice.

I’m expecting that, once the self-host check-all is fixed, we won’t have problems here. The few check-all problems (about 3) seem to be regarding configuration, not real bugs in the compiler, so I’m not expecting any problem in the self-hosting test-suite.

But it’ll take a while to create the bots. There were some, er, issues with the Arndale (http://www.spinics.net/lists/kvm-arm/msg03723.html) and the Chromebooks are not the best rack machines… :wink:

Anyway, my aim is to get those 4 bots up and green by the 3.3 release.

cortex-a9 sounds fine. It’d be cool if we verified those binaries

run on a cortex-a8 and a cortex-a15, too. It’d be very, very strange
if they didn’t, but hey, catching very, very strange problems is what
release testing is for, right? :slight_smile:

Actually, this is a good idea, I’ll set up a Beagle as a buildbot and see what happens to it.

At least for now, I do think we should constrain “ARM is a supported
target” to mean armv7. For purposes of testing, armv6 is effectively
a different target.

I agree. LLVM does a pretty good job at compiling for other ARM architectures, but corner cases can be quite bad, and it’s usually on them that people will compare LLVM to GCC. A warning that we’re primarily focusing on v7 for the time being would be in order.

cheers,
–renato

Renato,

cortex-a9 sounds fine. It'd be cool if we verified those binaries
run on a cortex-a8 and a cortex-a15, too. It'd be very, very strange
if they didn't, but hey, catching very, very strange problems is what
release testing is for, right? :slight_smile:

Actually, this is a good idea, I'll set up a Beagle as a buildbot and see
what happens to it.

AFAIR, there were several beagles in LLVM Lab. You might want to check
with Galina about how live they are.

Hello everyone,

AFAIR, there were several beagles in LLVM Lab. You might want to check
with Galina about how live they are.

Yes, we have couple beagleboards. I can make them available if this will add value.

Maybe we should set a special “release” buildmaster? Which would orchestrate slow bootstrapped builds with extensive testing and collect binaries. This lets us unify the way how it gets built and formally tested. And would save testers time for more advance testing.

What do you think?

Thanks

Galina

Yes, we have couple beagleboards. I can make them available if this will
add value.

I think a simple ClangBuilder on it for now would be good. I'm looking into
getting a self-hosting Panda on my local buildmaster. If it works, I'll
send the patch. I'll only be able to look at beagle boards in a week from
now (holidays), so if you have them ready, feel free to use them.

Maybe we should set a special "release" buildmaster? Which would

orchestrate slow bootstrapped builds with extensive testing and collect
binaries. This lets us unify the way how it gets built and formally tested.
And would save testers time for more advance testing.

We thought about that for a while, but since the requirements we want for
builds are the same we want for CI, the idea was to create the
infrastructure for CI and only tag the good builds for release.

The collection of binaries is another story, I agree an automated way is
necessary, but I have little experience with that. I hear Jenkins can
do marvellous things, but I never used it, let alone configure it. Having a
buildbot just for the binaries would also work if at the end it'd push to a
release server (FTP/HTTP area for download).

cheers,
--renato

> If we do end up creating ARM binaries for the general public, your input
> and expertise will be greatly appreciated! :wink:
I will be happy to provide some Debian & Ubuntu ARM packages. I just
need access to ARM server(s).

  I don't know if there is such server available. If so, I also would
like give help. :slight_smile:

Regards,
chenwj

I think the arm binary is for linux. :slight_smile:

Regards,
chenwj

In the following page :

http://www.debian.org/ports/kfreebsd-gnu/

There is the following paragraph :

"
Available Hardware for Debian Developers

asdfasdf.debian.net (kfreebsd-amd64) and io.debian.net (kfreebsd-i386) are
available
to Debian developers for porting work.
Please see the machine database for more information about these machines.
In general, you will be able to use the two chroot environments:
testing and unstable. Note that these systems are not yet administrated by
DSA,
so do not send requests to debian-admin about it.
Instead use admin@asdfasdf.debian.net or admin@io.debian.net.
"

leading to the following page which contains ARM based computers :

http://db.debian.org/machines.cgi

I do not whether this is useful for you or not .

Please check and see whether you can use it for your development work or
not .

LLVM / Clang is an important project for FreeBSD also .

Thank you very much .

Mehmet Erol Sanliturk

FreeBSD is also an important platform to test, and it will inevitably ship
LLVM when Clang becomes the system compiler.

David, it'd be good to have any reduced troubling case as a test in
check-all during the migration to LLVM.

cheers,
--renato

It is very exciting to see experimental Windows support listed for 3.3.

Is there documentation somewhere that tracks what works and what doesn’t in this configuration, particularly for C++?. Otherwise it is difficult for those not actively involved in developing Windows support to know what to expect when experimenting.

Thanks,
Andrew

Hi Andrew,

Anton is the maintainer of the Windows port. I’ve CC’ed him to this email so that he can comment.

-bw

I agree FreeBSD is also a important platform. What I mean is, although FreeBSD
change its system compiler to clang/LLVM, shipping the ARM binaries is still
needed as that's for Linux.

Regards,
chenwj

Hi Mehmet,

  Thanks for the info. I just contacted DSA (Debian System Admin, I
guess), and he said we have to prepare information list on [1] and
ask DD to approve it. Are you a DD, or Sylvestre is?

Regards,
chenwj

[1] http://dsa.debian.org/doc/guest-account/