search for: chandlers

I did try that, but had difficulties in compiling it from source-- it's not in the yum repositories (either CentOS or Dag Wieers). -- Jay Chandler Network Administrator, Chapman University 714.628.7249 / chandler at chapman.edu Ethernet, n. What one uses to catch the Etherbunny. -----Original Message----- From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf Of

This time with the correct mailing list address... See below... On Wed, Mar 11, 2015 at 3:07 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > Why? > > 1) We're moving away from autoconf already today. We're hoping to drop it > completely soon. > 2) It doesn't work today and no one is complaining. > 3) It hasn't worked for weeks and no one has

I suspect the answer is "no" as it dies with a hard error for me. I don't want to fix this if it isn't being used; I would rather delete it and avoid the complexity it brings. Thoughts? This came up because I have changes to LLD's CMake build to support LLVM_LIBDIR_SUFFIX more effectively, but I can't test them in a standalone build. -Chandler -------------- next part

FYI, I ran some initial measurements just for sanity on the test-suite on x86-64: Total stack frame size: 13362520 -> 13365864 (+0.02%) Average stack frame size: 581.814 -> 581.96 (+0.02%) Average compile time: 5.71178 -> 5.67256 (within noise) Number of functions is exactly the same, so no trivially visible inlining decision changes. I've spot checked a few of the functions that

Got most of my install woes sorted out. Have Dovecot running on two servers, one for my standard imap deployment, and one for my webmail server. I'm getting a lot of messages like this when my palm Treo syncs. Anyone have any idea what I have set wrong? Jan 17 21:49:57 montreal dovecot: imap-login: Login: user=<chandler>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Jan 17

On Sat, Jan 23, 2016 at 6:42 AM, Eric Christopher via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Rafael, > > This is an unreasonable and unacceptable escalation of this thread. You have > been dismissive, derailing, and taking out of context everything Chandler, > and other long term active contributors have been asking and talking about. > Your tone has been

(Sorry for CC'ing piles of people, but didn't want folks to miss this in the mailing list churn.) See the subject. The problem is in the target-independent code generator and especially in the x86 backend. I would like to fix it. This will be a mechanical change just organizing code in a way that makes it easy and fast to find methods and related static helpers. It will not change any

Hi Chandler, I'm still migrating our bots, there were some complications. Can it wait until next week? cheers, --renato On 13 January 2014 22:00, Chandler Carruth <chandlerc at gmail.com> wrote: > FYI, this is happening now-ish! > > > On Tue, Jan 7, 2014 at 1:40 AM, Chandler Carruth <chandlerc at gmail.com>wrote: > >> Greetings, starting a new thread and

That is what I'm proposing, and Tim is helping us test. We should reach a solution quickly, and once we do, I'll update the document. Feel free to try his repo, I'll only try tomorrow. If you guys come up with a clear flow before that, let me know. Cheers, Renato On 20 Jul 2016 12:36 a.m., "Chandler Carruth" <chandlerc at google.com> wrote: > I've not read

Can you say what Benchmark or give a test case so we understand the nature of the regression? As Gerolf said, that will be important to understand what is best to do. On Fri, Jul 17, 2015, 06:43 Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> wrote: > Yes, the regression is stable. I double checked this. A full benchmark > run consists of at least 10 sub-runs to validate the

> > Having read all of these threads, I am thoroughly convinced by the positions put forward by others. > Chandler, others have decided to let the compiler continue mis-compiling the function-inlining example, others have decided to not fix the inability to hoist a loop invariant divide out of a loop. It sounds like you haven’t even thought about these things let alone

The MBlaze backend seems to be essentially unmaintained since 2011. The maintainer (Wesley Peck who is BCC'ed) seems to have vanished, and in fact all emails to him are bouncing. I propose to remove the MBlaze backend on Friday if none step forward as a maintainer. Currently, folks are having to keep it up to date when changing shared parts of the backend with no help. -Chandler

I have fixed the issue locally, but been out of the office - can apply the fix - or just maintain the makefiles locally if no-one else really wants them, fine with whatever the community decision is. Iain On 11 Mar 2015, at 22:11, Rui Ueyama wrote: > I'd agree, but the Makefiles were added just 9 months ago. I don't know if there's a real need of any kind. Added Iain who added

On Tue, Sep 9, 2014 at 11:39 PM, Chandler Carruth <chandlerc at google.com> wrote: > Awesome, thanks for all the information! > > See below: > > On Tue, Sep 9, 2014 at 6:13 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> > wrote: >> >> You have already mentioned how the new shuffle lowering is missing >> some features; for example, you explicitly

On Sat, Sep 14, 2013 at 3:57 PM, Reed Kotler <rkotler at mips.com> wrote: > Hi Chandler, > > What changes are you planning to make? > > Are you going to submit a proposal and RFC? > There have been several RFCs... What's your specific question? I'm planning to essentially try to build a new pass management layer that doesn't suffer from the problems the

Dear Wine community, Ubuntu 10.04 Wine 1.1.42 chandler is a great program to manage todos and we use it among collegues to assign tasks and it syncs with its own online hub perfectly. I haven't found any alternatives as good as chandler. In order to get it to work in ubuntu i have tried it via wine. This is chandler in case you don't know it: http://chandlerproject.org/ Chandler loads,

Greetings. I've got a poorly conceived and implemented system I'm trying to migrate off of. Right now we've got 20K accounts or so, in mbox form, under UW-IMAP. Eventually we're going to move to Maildir format, but the first step is to move to Dovecot on one of our imap servers as a proof of concept. In other words, all config changes have to take place on the dovecot

Before the fix, the compiler may simply return 'noalias' for cases it can not really prove to be noalias, but actually correct by luck (or even wrong noalias, but does not result in miscompile). It would be useful to find out the set of missed noalias queries from GlobalModRef with your benchmark and examine if there is some improvement can be done. David On Fri, Jul 17, 2015 at 6:32

I ran the benchmarking subset of test-suite on a btver2 machine and optimizing for btver2 (so enabling AVX codegen). I don't see anything outside of the noise with x86-experimental-vector-shuffle-legality=1. On Fri, Jan 23, 2015 at 5:19 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com > wrote: > Hi Chandler, > > On Fri, Jan 23, 2015 at 8:15 AM, Chandler Carruth

My 2 cents: get rid of LLVM_UNUSED_RESULT, and move to LLVM_NODISCARD. For compilers that support it, it should be a strict superset of features and functionality. The standard feature was written directly based on the clang warn_unused_result stuff. I would just migrate us onto the spelling and usage pattern that got standardized. All we have to lose are warnings from compilers other than Clang