similar to: [LLVMdev] Patch for 3.2

The reassociate patch is also ok with me. -Chris On Nov 21, 2012, at 2:26 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Pawel, > >> I would like to merge r168035, r168181 and r168291 as >> one reassociate changeset: > > r168181 has nothing to do with reassociate, so should be separate. r168035 and > r168291 have no logical connection so I don't think

Fwiw, I approve both of these patches if they are still unmerged. -Chris On Nov 18, 2012, at 11:41 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Pawel, > >>> Can you provide some examples of the problems you are seeing? >> >> Here is what happens. >> >> I get a message "could you please include/add/merge this r16xxxx into >>

Hi Pawel, > I would like to merge r168035, r168181 and r168291 as > one reassociate changeset: r168181 has nothing to do with reassociate, so should be separate. r168035 and r168291 have no logical connection so I don't think they should be merged as one changeset. > Have you heard from Chris regarding r168291? >

Duncan, I would like to merge r168035, r168181 and r168291 as one reassociate changeset: Have you heard from Chris regarding r168291? http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156364.html Pawel > On 20/11/12 05:57, Chris Lattner wrote: >> Fwiw, I approve both of these patches if they are still unmerged. > ... >>>

Hi Pawel, >> Can you provide some examples of the problems you are seeing? > > Here is what happens. > > I get a message "could you please include/add/merge this r16xxxx into > 3.2?". And my immediate reaction is sure, no problem this fixes > PR/issue/crash so it is important. But are you the code owner > and do you approve? So I have to go and start checking

> On Sat, Nov 17, 2012 at 7:40 PM, Pawel Wodnicki <pawel at 32bitmicro.com>wrote: > >> On 11/17/2012 6:35 PM, Chris Lattner wrote: >>> >>> On Nov 17, 2012, at 9:57 AM, Nadav Rotem <nrotem at apple.com> wrote: >>> >>>> I think that the code owner process is becoming complicated and I am >> not sure if it serves Chris's

On 20/11/12 05:57, Chris Lattner wrote: > Fwiw, I approve both of these patches if they are still unmerged. ... >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/155994.html >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156206.html Thanks Chris. Can you please also give your go ahead for this nasty reassociate infinite loop

Hi Pawel, can you please pull this fix http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/155994.html into the 3.2 branch. It fixes a crash in the reassociate pass. I think it is low risk. Thanks, Duncan.

Hi Pawel, can you please pull this dragonegg patch into 3.2. I am the code owner for dragonegg. Thanks a lot, Duncan. On 28/11/12 13:44, Duncan Sands wrote: > Author: baldrick > Date: Wed Nov 28 06:44:50 2012 > New Revision: 168787 > > URL: http://llvm.org/viewvc/llvm-project?rev=168787&view=rev > Log: > Add support for GCC's vector copysign builtins, fixing

On Sun, Nov 18, 2012 at 11:41 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Pawel, > > >>> Can you provide some examples of the problems you are seeing? >> >> >> Here is what happens. >> >> I get a message "could you please include/add/merge this r16xxxx into >> 3.2?". And my immediate reaction is sure, no problem this

Hi Pawel, I guess the code owner could be noted in each source file. Eg: in SelectionDAGBuilder.cpp, there could be a line in the comment block at the start: // Code owner: Owen Anderson (resistor at mac.com) Then anyone working on a bug or with questions about code instantly knows who to turn to. Ciao, Duncan.

Alright, can you please pull in r169280? On Tue, Dec 4, 2012 at 12:56 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote: > On 12/4/2012 10:14 AM, Justin Holewinski wrote: > > What is the procedure for updating the release notes? I've been > committing > > changes to the trunk version, should I be editing them elsewhere? Or > will > > the trunk version be

I think that the code owner process is becoming complicated and I am not sure if it serves Chris's original intent. I don't think that we need to change every file nor do we need an automatic tool to find the owner. I think that a simple text file, or a section in the docs is enough. On Nov 17, 2012, at 2:51, Duncan Sands <baldrick at free.fr> wrote: > Hi Pawel, I guess the code

Pawel, First, all your help with the 3.2 release is greatly appreciated. I do not think anyone is saying otherwise. I apologize for the lack of documentation regarding this issue. I do ask that you consult with previous release manager (myself or Bill) to determine what the best course of action is. There is a lot of room to improve our release process, but its a collaborative effort. You are

On 12/4/2012 10:14 AM, Justin Holewinski wrote: > What is the procedure for updating the release notes? I've been committing > changes to the trunk version, should I be editing them elsewhere? Or will > the trunk version be merged in? The exact procedure is not spelled out but I think the easiest would be to merge relevant "ReleaseNotes.html" changes from the trunk,

On Nov 13, 2012, at 11:16 AM, Pawel Wodnicki <pawel at 32bitmicro.com> wrote: > Bill, > >> Hi Pawel, >> >> Could you branch polly as well for the 3.2 release? We will need to contact the 'polly' guys to figure out how best to add it to the release (testing, etc.). > > Sure. > > But I do not know much about polly so 'polly' guys please

Tanya, > Pawel, > > First, all your help with the 3.2 release is greatly appreciated. I do not think anyone is saying otherwise. Nothing was said so nothing to worry about. > > I apologize for the lack of documentation regarding this issue. I do ask that you consult with previous release manager (myself or Bill) to determine what the best course of action is. There is a lot of

Akira, > Pawel, > > Is it still not too late to merge these patches? > > r168471 > r168460 > r168458 > r168456 > r168455 > r168453 > r168450 > r168448 > > These patches fix a bug in mips backend's GOT implementation and add > support for big-GOT relocations. That's quite a list of patches! To get them into the 3.2 release you would first

Hi Eli, > Have you tried implementing computeMaskedBitsForTargetNode for your > setcc nodes? If you have, I think DAGCombiner should take care of the > necessary simplification. he doesn't need to: the DAG combiner knows all about SetCC values, and should simplify this already. Ciao, Duncan.

Anton, > Pawel, > > We all understand that you're pretty new to release process, etc., but > I think you should understand the implications of your actions. > > You just created a lot of harm for really huge pile of users - the > ones who downloads the tarball via some automated build system and > rely on the known good checksum. This includes, but not limited to to