similar to: [LLVMdev] Announcement: 2.9rc2 Delay

On 05/20/2015 11:04 AM, Renato Golin wrote: > On 20 May 2015 at 18:47, Philip Reames <listmail at philipreames.com> wrote: >> One particular irritant is getting emails 12-24 hours later about someone else's >> breakage that has *already been fixed*. The long cycling bots are really >> irritating in that respect. > That's not that easy to fix, and I think

Not yet. That is, I don't think any have been filed at all for 3.0. I don't know whether to be happy or worried. :-) Any that are regressions should be marked with the 'regression' keyword and be a release blocker. -bw On Oct 20, 2011, at 8:40 AM, Jim Grosbach wrote: > Hi Bill, > > Do we have a list of which PRs have been filed that are considered release blockers?

On Jul 22, 2011, at 3:33 PM, fly language wrote: > > After git, mainline will still be the most important branch for the *project*, > but you will work with quite a few branches on parallel. > > > Who's mainline? :) Be prepared to assign a super-merger, like Linus, to maintain the "mainline". > > The git workflow works really really great, but it does

On Sep 8, 2011, at 9:13 PM, David A. Greene wrote: > Bill Wendling <wendling at apple.com> writes: > >>> In other words, svn is not a distributed SCM. It has long struck me as >>> odd that a project whose license encourages private copies would stick >>> with an SCM that has no support for keeping such copies. >>> >> It's my

On Feb 6, 2013, at 2:02 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Bill Wendling <wendling at apple.com> writes: > > [snip] > >> Welcome to living on the top-of-tree! :-) >> >> We are in between releases. It's expected that the APIs will be >> unstable. [snip] > > One thing is an unstable API, and a different thing is a code base

On Jul 23, 2011, at 5:37 AM, FlyLanguage wrote: >>>> After git, mainline will still be the most important branch for >>>> the *project*, >>>> but you will work with quite a few branches on parallel. >>>> >>>> >>>> Who's mainline? :) Be prepared to assign a super-merger, like Linus, >>>> to maintain

On Jul 17, 2009, at 9:53 AM, Marcel Moolenaar wrote: >> >> At this point, I think we should remove the Itanium backend from >> mainline. I would be thrilled if you would take it and fix it up and >> get it working out of tree. If you get it working on significant >> programs (regardless of the performance of those programs) we'd >> definitely accept it

Hi Bill, Do we have a list of which PRs have been filed that are considered release blockers? -Jim On Oct 17, 2011, at 4:33 PM, Bill Wendling wrote: > Hi all, > > Testing for LLVM 3.0 release candidate 1 is now under way! We will soon have binaries available for you to download and try. Those who would like to compile things and try them out for themselves can grab the source

On Jul 22, 2011, at 3:45 PM, Bob Wilson wrote: > > On Jul 22, 2011, at 3:33 PM, fly language wrote: > >> >> After git, mainline will still be the most important branch for the *project*, >> but you will work with quite a few branches on parallel. >> >> >> Who's mainline? :) Be prepared to assign a super-merger, like Linus, to maintain the

Hi all, Testing for LLVM 3.0 release candidate 1 is now under way! We will soon have binaries available for you to download and try. Those who would like to compile things and try them out for themselves can grab the source tarballs here: http://llvm.org/pre-releases/3.0/ A Word About Patches I neglected to send out instructions on how to get patches into the LLVM 3.0 branch. All patches must

On Thu, 12 May 2016 16:40:44 +0100 David Chisnall via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > The end result is that shortly after a release (sometimes every alternate release) is branched a load of downstream projects update to the new APIs, test things, and find a bunch of regressions that have been sitting in the tree for months. We then have to scrabble to bisect and try

Hi again, On my PPC G4 box, I'm getting this failure for TOT with llvm-gcc 4.2: Running /Users/wendling/llvm/llvm.src/test/CodeGen/X86/dg.exp ... FAIL: /Users/wendling/llvm/llvm.src/test/CodeGen/X86/2008-02-18- TailMergingBug.ll for PR1909 Failed with exit(1) at line 1 while running: llvm-as < /Users/wendling/llvm/llvm.src/test/CodeGen/ X86/2008-02-18-TailMergingBug.ll | llc -march=x86

On Fri, Mar 25, 2011 at 15:07, Bill Wendling <wendling at apple.com> wrote: > Hi all, > > Well! we had a rather fruitful phase 1 testing round. Several issues were > addressed. After a bit of a delay, we are ready for phase 2 testing. > > This phase is to make sure that no patches submitted to fix problems and > complete features in phase 1 caused further difficulties.

On Tue, Jan 27, 2009 at 1:15 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Jan 27, 2009 at 1:00 PM, Bill Wendling <isanbard at gmail.com> wrote: >> Even with C code, we place a null string in a writable >> section, which isn't correct. > > You could say that, but it's not really wrong... say you had a 10 > kilobyte struct that was all

On Jul 27, 2011, at 8:02 AM, Chris Lattner wrote: > On Jul 27, 2011, at 1:08 AM, Bill Wendling wrote: > >>>> Progress Report: >>>> >>>> I created the two new instructions: landingpad and resume. Hand-modified code can run through the assembler and disassembler and emit the same code. The verifier can verify basic properties of the landingpad

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #39 from Andreas Loew <awl1 at gmx.net> --- > You really want to be doing a git bisect to do the least amount of work; I > don't see what you mean by "move forward" but I really hope that you are > testing the commits in a binary tree style. Yup. Indeed, I am trying to use a "binary" approach to

On Tue, 19 Feb 2008, Bill Wendling wrote: > On my PPC G4 box, I'm getting this failure for TOT with llvm-gcc 4.2: Fixed. -Chris > FAIL: /Users/wendling/llvm/llvm.src/test/CodeGen/X86/2008-02-18- > TailMergingBug.ll for PR1909 > Failed with exit(1) at line 1 > while running: llvm-as < /Users/wendling/llvm/llvm.src/test/CodeGen/ > X86/2008-02-18-TailMergingBug.ll | llc

The LLVM 3.0 release branch has been tagged. You may now commit patches at your leisure. Thank you for keeping the ToT healthy! -bw

On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote: > Darwin/ppc: > SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ] > From what I can see comparing 2.3 with TOT, the "cexp" function is declared like this in 2.3: declare i128 @cexp({double, double}* byval) nounwind It used to be this: declare void @cexp({double, double}* noalias sret, {double, double}* byval)

On Feb 6, 2013, at 2:42 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Bill Wendling <wendling at apple.com> writes: > >> Using a development branch and then slamming those changes into trunk >> is at odds with the llvm style incremental development philosophy. > > In this case, the LLVM incremental style is counterproductive, for both > users and