similar to: [LLVMdev] test-suite for 2.8

On Dec 6, 2010, at 9:31 AM, David Greene wrote: > Is there a reason there is no RELEASE_28 tag for test-suite? > SVN wouldn't allow me to make one. -bw -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101207/c87515cd/attachment.html>

Bill Wendling <wendling at apple.com> writes: > On Dec 6, 2010, at 9:31 AM, David Greene wrote: > > Is there a reason there is no RELEASE_28 tag for test-suite? > > SVN wouldn't allow me to make one. So getting the latest release_28 branch should be equivalent, yes? I just want to make sure we have a way to test 2.8 long-term. -Dave

Hello all, According to: http://llvm.org/releases/2.8/docs/GettingStarted.html#checkout folks can check out a specific release from Subversion. As of right now, RELEASE_28 contains folders for each of the release candidates, as opposed to the final content. Same goes for Clang. -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi David > I think the trouble with branches is the lockdown of the root repository > directory. Surely not (at the server) > git svn init --stdlayout https://<user>@llvm.org/svn/llvm-project/llvm \ >

Important Announcement Release testing of Release Candidate 1 is finished. I'll be tagging Release Candidate 2 tonight. If there are any fixes you want in, please get them approved as soon as possible. After this tag, the only patches that will be accepted will be those that fix regressions from 2.7 -bw -------------- next part -------------- An HTML attachment was scrubbed... URL:

Oliver Schneider <gmane at assarbad.net> writes: >>> However, we have official git mirrors of most of the projects on >>> llvm.org, would using them instead of svnsync be an option for you? >> >> Well, if the authoritative source code control system for all the >> llvm projects is svn, I'd just as soon use svn as the tool at my end. > The git

Forgot to CC the list. I'm looking into it. -Dave ---------- Forwarded Message ---------- Subject: Re: [LLVMdev] Bootstrap Failure Date: Thursday 12 November 2009 15:50 From: David Greene <dag at cray.com> To: Bill Wendling <wendling at apple.com> On Thursday 12 November 2009 15:49, you wrote: > These are the likely culprits. David, it looks

On 03/07/2011 08:30 PM, Anton Korobeynikov wrote: > Hi David > >> I think the trouble with branches is the lockdown of the root repository >> directory. > Surely not (at the server) > >> git svn init --stdlayout https://<user>@llvm.org/svn/llvm-project/llvm \ >>

On Sep 15, 2010, at 12:46 AM, Albert Graef wrote: > Bill Wendling wrote: >> Release testing of Release Candidate 1 is finished. I'll be tagging >> Release Candidate 2 tonight. If there are any fixes you want in, please >> get them approved as soon as possible. > > Are there any tarballs for the release candidates available? Tanya used > to make these available

On Wed, 15 Sep 2010 01:50:24 -0700 Bill Wendling <wendling at apple.com> wrote: > On Sep 15, 2010, at 12:46 AM, Albert Graef wrote: > > > Bill Wendling wrote: > >> Release testing of Release Candidate 1 is finished. I'll be tagging > >> Release Candidate 2 tonight. If there are any fixes you want in, > >> please get them approved as soon as

On 1 Oct 2010, at 13:35, Bill Wendling wrote: > On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: > >> Bill Wendling wrote: >>> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >>> >>>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >>>> >>>>> Our architecture has 1-bit boolean predicate registers. >>>>>

Hi Dave, > We ran into a similar problem in our custom code here. To work around > it I modified Debug.h like this: > > #ifdef NDEBUG > static llvm::OStream NullStream(0); > #define DOUT llvm::NullStream > #else > #define DOUT llvm::getErrorOutputStream(DEBUG_TYPE) > #endif > I thought about doing this, but there's the potential for naming conflicts that

Good day! To get ready for the release, we need to make sure that the list of external open source projects using LLVM 3.0 (file:///Volumes/Sandbox/llvm/llvm.src/docs/ReleaseNotes.html#externalproj) is up to date. Please send me an email with the project's name and a short description of it. Alternatively, if the project was commented out and you would still like to be listed, just tell me

On Sep 21, 2010, at 10:23 AM, Nicolas Capens wrote: > Hi all, > > Sorry for the late reply. I got sidetracked by other fun projects. ;-) > > I found that the performance regression is caused by revisions 112804, > 112805 and 112806. Those changes were made 2 days prior to the 2.8 > branching, so it may have not been the intention to include them there? > Either way they

Good news, everybody! It's that time of year again. We are going to release LLVM 2.8! I'm taking over for Tanya to give her a much needed break. I can only hope to perform as well as she has. This is my first time as release manager, so bear with me if things don't go smoothly. This message is mostly to give you an idea of the schedule we're planning on. It's an aggressive

On Apr 30, 2012, at 1:00 PM, dag at cray.com wrote: > Bill Wendling <wendling at apple.com> writes: > >> Link-Time Optimization has a problem. We need to preserve some of the >> flags with which the modules were compiled so that the semantics of >> the resulting program are correct. For example, a module compiled with >> `-msoft-float' should use library

Hi David, Yes. It was the main reason why I decided to do an RC3. :-) -bw On Mar 28, 2011, at 10:41 AM, David Terei wrote: > Hi Bill, > > Is the fix for Bug 9561 included? (http://llvm.org/bugs/show_bug.cgi?id=9561) > > Cheers, > David. > > On 26 March 2011 18:38, Bill Wendling <wendling at apple.com> wrote: >> Hi all, >> >> The good news:

Hi all, The good news: RC2 testing was successful in that it uncovered a bad regression from 2.8 (which existed in top-of-tree). It also showed that there was an unincorporated fix that needed to go into the clang branch. The bad news: I'm truncating the RC2 testing phase and announcing the RC3 testing phase. Hopefully, because we caught the bugs in time this phase won't impact the

> In your svn section of llvm/.git/config, you can specify how to map > the svn branches to different name spaces, something like this: > > [svn-remote "svn"] >        [...] >        branches = branches/*:refs/remotes/origin/* >        fetch = branches:refs/remotes/origin > > I would also change "branches = branches/*:refs/remotes/origin/*" > into

Assign the bug to me and I'll fix it in TOT next week! Thanks for narrowing it down! On Wednesday, September 22, 2010, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi all, > > I think I figured it out: > 112804 causes 64-bit UNPCKLBW to no longer be selected for certain cases. > 112805 is benign. > 112806 causes 64-bit UNPCKHBW to no longer be selected for