similar to: [LLVMdev] [Announcement] 3.3 Release Planning!

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 On Mon, Apr 1, 2013 at 5:05 PM, Bill Wendling

On 1 April 2013 22:05, Bill Wendling <wendling at apple.com> wrote: > We would like to support ARM again. > Hi Bill, Glad you asked! ;) 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

On Apr 3, 2013, at 2:07 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 1 April 2013 22:05, Bill Wendling <wendling at apple.com> wrote: > We would like to support ARM again. > > Hi Bill, > > Glad you asked! ;) > > 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

On 1 Apr 2013, at 22:05, Bill Wendling <wendling at apple.com> wrote: > • 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

IMPORTANT! IMPORTANT! IMPORTANT! We will be branching for the 3.1 release on April 16th! :-) This gives us a little over two weeks to get the trees into the most stable condition we can. What this means for you: All major features for the 3.1 release should be finished or near completion by the April 16th. After April 16th, we will accept only bug fixes and patches which do not change the

> By the way, we are looking for ARM testers. There was a lot of interest in the 3.0 release for an ARM release. We will try to do one this release on a trial basis. We are looking for ARMv7 cortex-a8 and cortex-a9 on Linux. We have two pandard board (ARMv7 cortex-a9) and perhaps one ARMv6 4-cores board. Do we do a native compile or cross compile for the ARM platform? Regards, chenwj --

Le mardi 27 mars 2012 à 14:36 -0700, Bill Wendling a écrit : > IMPORTANT! IMPORTANT! IMPORTANT! > [...] > By the way, we are looking for ARM testers. There was a lot of interest in the 3.0 release for an ARM release. We will try to do one this release on a trial basis. We are looking for ARMv7 cortex-a8 and cortex-a9 on Linux. If you are interested, I can upload the current trunk

On Mar 29, 2012, at 2:46 AM, 陳韋任 <chenwj at iis.sinica.edu.tw> wrote: >> By the way, we are looking for ARM testers. There was a lot of interest in the 3.0 release for an ARM release. We will try to do one this release on a trial basis. We are looking for ARMv7 cortex-a8 and cortex-a9 on Linux. > > We have two pandard board (ARMv7 cortex-a9) and perhaps one ARMv6 > 4-cores

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? :) > Actually, this is a good idea, I'll set up a Beagle as a buildbot and see > what happens to

On 3 April 2013 21:15, Bill Wendling <wendling at apple.com> wrote: > > > * 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. :) Great! This is feasible for the 3.3 time frame.

It's probably PR12517. Looking at the clang binary, it's got a /home/ dir in RPATH: $ objdump -p clang+llvm-3.3rc3-Ubuntu-12.04.2-x86_64/bin/clang | grep RPATH RPATH $ORIGIN/../lib:/home/aadgrand/tmp/LLVM-3.3rc3/rc3/Phase3/Release+Asserts/llvmCore-3.3-rc3.obj/Release+Asserts/bin This will slow things down if the system tries to automount /home/aadgrand. Maybe we should merge r182559

Hi all, In revision 223114 I committed a fix to clang project. It caused fail on clang-native-arm-cortex-a9: http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/23599. According to logs it was a problem with memory allocated by malloc. Reverting the fix in 223120 made the bot green. The changed code does nothing with heap, none of other bots failed, so it looks like a platform

Hear ye! Hear ye! This is a call for testers for the 3.3 release!!! What's Expected --------------- You might be asking yourself, "Self, I would like to be an LLVM tester for the 3.3 release, but I don't know what's involved in being one." Well, ask yourself no more! Not only do I have the answers for you, but talking to yourself will cause people to avoid you. Here's

On 24/04/2013 12:53, 陳韋任 (Wei-Ren Chen) wrote: > Hi Sylvestre, > >>> 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? >> I am (cf my email address). >> Why would like to do in this context ? > >

On Wed, Apr 03, 2013 at 10:24:13AM +0100, David Chisnall wrote: > On 1 Apr 2013, at 22:05, Bill Wendling <wendling at apple.com> wrote: > > > • 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

Hi Galina, folks, Does anyone have an idea why the A9 bots are unstable on Clang? They all seem to be the same problem: 1. <eof> parser at end of file Segmentation fault http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/26073/steps/check-all/logs/Clang%3A%3Adead-stores.c

Folks, I know it's a reasonably valuable thing to have the buildbot IRC bot publishing results, but the channel is kind of flooded with the messages, and the more bots we put up, the worse it will be. I think we still need the NOC warnings, but not over IRC. The Buildbot NOC page is horrible and useless, since it doesn't know the difference between "it's red and I know it"

Hi, I had a quick look at that link and it seems to be a linker internal error. Presumably we're triggering a bug in the system toolchain. FWIW, my mipsel build on a Debian Jessie machine (binutils 2.24.90.20141023-1) successfully completed test-release.sh. I'm currently running the tests. Here's the relevant bit of the log from your link: cd

> Test suite is green but I'm seeing two libc++ test failures when running check-all. What tests are failing? On Fri, Jun 10, 2016 at 5:13 PM, Nikola Smiljanic via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Uploaded Fedora and openSUSE binaries. Test suite is green but I'm seeing > two libc++ test failures when running check-all. I'm pretty sure these were >

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