similar to: Fwd: buildbot failure in LLVM on clang-ppc64-elf-linux2

On Tue, 2015-09-29 at 14:29 -0500, Hal Finkel wrote: > [+Bill and Bill] > > ----- Original Message ----- > > From: "David Blaikie via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "llvm-dev" <llvm-dev at lists.llvm.org> > > Sent: Tuesday, September 29, 2015 12:39:02 PM > > Subject: [llvm-dev] Fwd: buildbot failure in LLVM on

Hi, My New Year's resolution is to complain (constructively) whenever I get a spurious build failure email from a buildbot. For new or infrequent contributors especially, they can be extremely confusing and unnecessarily alarming. This one below is the first build ever attempted by the builder, so how on earth can it have come up with a meaningful blame list? And in any case, surely we

This builder is taking too long to build. (The build stops because of a timeout.) Chip On Aug 30, 2013, at 11:29 AM, llvm.buildmaster at lab.llvm.org wrote: > The Buildbot has detected a new failure on builder clang-amd64-openbsd while building llvm. > Full details are available at: > http://lab.llvm.org:8011/builders/clang-amd64-openbsd/builds/1103 > > Buildbot URL:

Chandler Carruth <chandlerc at gmail.com> wrote: > I've been working to revive the PPC64 build bots, and succeeded, but > not for the right reasons. There were still bootstrap assertion > failures and other pretty blatant errors. Then we figured out why: > the Clang bootstrapping build bots for Power7 are not actually > running any of the Clang tests! > > Could one

Hey Galina, Will; I've been working to revive the PPC64 build bots, and succeeded, but not for the right reasons. There were still bootstrap assertion failures and other pretty blatant errors. Then we figured out why: the Clang bootstrapping build bots for Power7 are not actually running any of the Clang tests! Could one of you tweak this build bot's configuration to match the other

On 10.12.2012, at 15:19, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote: > Chandler Carruth <chandlerc at gmail.com> wrote: > >> I've been working to revive the PPC64 build bots, and succeeded, but >> not for the right reasons. There were still bootstrap assertion >> failures and other pretty blatant errors. Then we figured out why: >> the Clang

Benjamin Kramer <benny.kra at gmail.com> wrote on 11.12.2012 12:48:55: > On 10.12.2012, at 15:19, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote: > > Maybe I'm confused somehow, but I thought this one: > > http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2 > > does bootstrap and then run both LLVM and Clang tests (successfully): > >

I get some failing tests from compiler-rt. FAIL: cfi :: cross-dso/stats.cpp (30831 of 30893) ******************** TEST 'cfi :: cross-dso/stats.cpp' FAILED ******************** Script: -- /usr/local/google/home/prazek/llvm-build-release/./bin/clang -fuse-ld=gold -flto -fsanitize=cfi -fwhole-program-vtables --driver-mode=g++ -fsanitize-cfi-cross-dso -fvisibility=default -DSHARED_LIB -fPIC

There seem to be some recent regressions in clang/llvm. I see some test failing, and there is also this issue: https://llvm.org/bugs/show_bug.cgi?id=30466 Is anyone working on it? Piotr -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160920/ade5e8cd/attachment.html>

--- On Thu, 9/20/12, Jim Grosbach <grosbach at apple.com> wrote: From: Jim Grosbach <grosbach at apple.com> Subject: Re: [LLVMdev] Proposal: New DAG node type for reciprocal operation To: "Weiming Zhao" <weimingz at codeaurora.org> Cc: llvmdev at cs.uiuc.edu Date: Thursday, September 20, 2012, 3:32 PM Sounds like a reasonable fit for a target-specific DAG combine. I

Yes, what I mean is a target independent node in the ISD::NodeType enum. I already did the node transformation DAGCombiner and target-specific lowering in the first place. It worked. But introducing a specific node will make the logic more clear. For example, in ARM, FDIV is a scalar operation. So, after DAGCombiner and Vector Type legalize, vectorized FDIV has been expanded into scalar versions,

Hi Since the buildbot host was updated to Fedora F20 levels, the clang buildbot has been failing with the following: $ /home/clangbuild/clang-ppc64-1/lnt.venv/bin/lnt runtest --verbose --submit http://llvm.org/perf/submitRun --commit=1 nt --sandbox nt --no-timestamp --cc /home/clangbuild/clang-ppc64-1/llvm.install.1/bin/clang --cxx /home/clangbuild/clang-ppc64-1/llvm.install.1/bin/clang++

On 09/29/2015 01:28 PM, David Blaikie via llvm-dev wrote: > The bot has been red and prone to (though not always - as Renato's > pointed out, a red bot that remains red may not send email, but purple > (exception)->red (even if it were red before the exceptional result) > does send email) send email on some of its failures, which adds noise > to the system and makes it

Hi Renato, It seems to me that LLVM doesn’t parse the inline asm body. It just checks the constraints, (ie. Input/output interface). During ASM writing, it then binding those constraints to placeholders like %0, %1. So it a constraint is a 64-integer type, it *probably* needs paired GPR. Weiming Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The

This probably needs broader discussion. We have an existing naming mechanism for polymorphic intrinsics; Elena is proposing a new one to avoid making the names for various load/store intrinsics particularly ugly. My personal take: 1) I like the cleaner naming scheme. 2) I'm not sure the additional complexity is worth it. (Not specific to the particular implementation proposed here.) 3) I

On Mar 13, 2013, at 10:15 AM, Weiming Zhao <weimingz at codeaurora.org> wrote: > Hi Renato, > > It seems to me that LLVM doesn’t parse the inline asm body. It just checks the constraints, (ie. Input/output interface). During ASM writing, it then binding those constraints to placeholders like %0, %1. This is correct. > So it a constraint is a 64-integer type, it *probably*

Hi, When I’m compiling a code with –fvisibility=hidden –fPIC for ARM, I find that LLVM generates less optimized code than GCC. For example: test.cpp: void init(void *); int g0[100]; int g1[100]; int g2[100]; void foo() { init(&g0); init(&g1); init(&g2); } Clang will emit 1 GOT entry for each GV and 2 instructions to get the address: ldr

Hi, In relaxed/fast math mode, if we can convert a/b to a * (1/b), we may get more performance when (1) "b" is loop invariant or (2) arch has faster reciprocal instruction (e.g. recipe/recips on ARM) or (3) arch has no vector div, but has vector mul and recip. So ,with this node type, a div node can be converted to a mul and a recip when desired. Then, each arch can further

This buildbot seems to have been failing for a while (though it's hard for me to identify the root cause in the logs, as I mentioned in another thread, so it's hard to say if it's the same failure, or if the failure is consistent, etc) - anyone watching it/caring aobut it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed, Sep 30, 2015 at

Per my previous email, I have just signed off on Artur's original patch. Philip On 03/02/2016 11:21 AM, Philip Reames via llvm-dev wrote: > Elena, > > I'd like to propose that we move forward withArtur's original patch > <http://reviews.llvm.org/D17270> and separate the discussion of how we > might change our intrinsic naming scheme. Artur's patch is