similar to: Buildbots do not detect test-suite failures!!!

I think what she is referring to was that the build seemed to be triggered by a commit to a project that shouldn't trigger builds on a libcxx bot (i.e. the change was in llvm). I have a somewhat orthogonal but related question. In the past, commits to compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has this behaviour been rectified with the move to github? I am really sorry

Sounds good to me. On 6/19/2017 2:27 PM, Davide Italiano via llvm-dev wrote: > On Mon, Jun 19, 2017 at 11:22 AM, Nemanja Ivanovic via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> For what it's worth, I just ran this on PowerPC and a double bootstrap with >> lit and lnt tests passes everything. >> > I fixed the only bug that has been reported (there were

For what it's worth, I just ran this on PowerPC and a double bootstrap with lit and lnt tests passes everything. On Sun, Jun 11, 2017 at 12:38 AM, Zhendong Su via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Sure, we are happy to start some testing to see what we may help find. > > On Sat, Jun 10, 2017 at 3:36 PM, Daniel Berlin <dberlin at dberlin.org> > wrote:

On 3 January 2013 21:53, David Blaikie <dblaikie at gmail.com> wrote: > That's how you achieve this goal. What a buildbot does is governed by > the configuration in the zorg repository (that's where we keep the > buildbot configuration code that is sync'd up to the lab.llvm.org > buildmaster). > Hi David, I had a go at Zorg after the website was back online. As

On Tue, Dec 27, 2016 at 3:22 PM, Nemanja Ivanovic via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I assume that this passes all the lit/lnt test cases on the platform that > the developers work on. > Yes I bootstrap/test it. > It causes 31 lnt test case failures on PPC. I've opened a bug with the one > that is easiest to reduce. > Also, I'm happy to assist

On 3 January 2013 20:53, Michael Gottesman <mgottesman at apple.com> wrote: > All of our internal testers use LNT. LNT behind the scenes just calls the > Makefiles appropriately. So it would be impossible to get rid of the > makefile execution without gutting LNT as well = p. > Hi Michael, The idea was never to gut the makefiles or LNT, but to let all buildbots use LNT to call

These are all caused by a set of failures to properly mark memory users as changed in some cases, and to initialize the memory operand equivalence table properly. I'm thinking how best to solve it. In the meantime, reverting the store equivalence changes should fix most of it (there is one other bug in updateReachableEdge that won't fix, where it misses marking memoryphi's) On Tue,

Can you share you compile-time and memory footprint measurements at least for CTMark? For a new pass/feature it would be great to share this with the community before you commit. Or did I miss them? Thanks Gerolf > On Jun 27, 2017, at 3:26 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > EarlyCSE w/ MemorySSA has been enabled by default as of r306477 >

On 3 January 2013 21:29, David Blaikie <dblaikie at gmail.com> wrote: > Fair enough - you could write up a patch for the zorg repository to do > this. > Wouldn't requiring every buildbot to use LNT achieve the same thing? --renato -------------- next part -------------- An HTML attachment was scrubbed... URL:

Sure. I didn't use lit or ninja. I simply copied the script produced by lit (/home/buildbots/ppc64le-clang-multistage-test/clang-ppc64le-multistage/stage1/tools/clang/test/Driver/Output/target-override.c.script) into a temporary directory (along with a deep copy of the build directory). I modified the paths in the script to point to the temporary directory. Then I ran the script in a loop. For

(and to be clear, reverting it would just hide the bugs pretty well, they'd fix it) I think i have a good way of fixing this properly, patch coming. On Tue, Dec 27, 2016 at 5:26 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > These are all caused by a set of failures to properly mark memory users as > changed in some cases, and to initialize the memory operand equivalence

I assume that this passes all the lit/lnt test cases on the platform that the developers work on. It causes 31 lnt test case failures on PPC. I've opened a bug with the one that is easiest to reduce. Also, I'm happy to assist by providing any further PPC specific information you require regarding this. Nemanja On Mon, Dec 26, 2016 at 9:55 PM, Mehdi Amini via llvm-dev < llvm-dev at

Should be fixed by https://reviews.llvm.org/D87103 Shall we consider deprecating(emitting a warning)/removing %T from lit? lldb, lld/COFF and clang-tools-extra are the three major users of %T. There are a few other %T in other places but there are not too many. We will also investigate whether other projects using lit are using %T. On Thu, Sep 3, 2020 at 11:25 AM David Blaikie <dblaikie at

This is likely due to a race condition (%T is a shared parent directory). I'll put up a patch to fix it. On Thu, Sep 3, 2020 at 10:00 AM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Is the machine running any jobs in parallel? Would it be worth trying running lit in the loop, rather than the script? (perhaps lit's doing something interesting) or maybe the

Hi, everyone, I'm currently the code owner for the PowerPC target. I worked on the PowerPC target for many years, and that was a lot of fun, but I've not been directly involved in development for PowerPC for some time. I would like to nominate Nemanja Ivanovic for the role of PowerPC target code owner. Insofar as a code owner is responsible for making sure that patches are reviewed,

https://llvm.org/docs/CommandGuide/lit.html already lists %T as "parent directory of %t (not unique, deprecated, do not use)". See also https://reviews.llvm.org/D35396 On Thu, Sep 3, 2020 at 3:37 PM David Blaikie <dblaikie at gmail.com> wrote: > Yeah, I think I'd be up for considering deprecation of %T due to the risk > of race conditions/conflicts between tests. %t

I think that was maybe the discussion on https://reviews.llvm.org/D78245 On Thu, Sep 3, 2020 at 6:22 PM Robinson, Paul <paul.robinson at sony.com> wrote: > I have a vague memory that libcxx wanted it for something, and claimed it > would be hard to work around not having it. > > Anyone else remember that? I can’t dredge up the details, sorry… > > In any event, a separate

Looks like I can't access git, documentation, bugs... I'm not sure if this email will actually go through. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171009/e63b709a/attachment.html>

Well, I am at my wit's end. I have copied over the script and directories for this test case and run it a few million times. First I was running one at a time, then I switched to kicking off 1000 at a time. All the while, the bots continued to run on the same machine. The script never failed even once. I am not sure if this has something to do with Python as part of llvm-lit or what is going

Quentin, thanks so much for looking at this. I should have noticed the other spill to the same stack slot if control doesn't flow through block 2 (line 32). I am sorry to have wasted your time. For the original issue, we won't be able to do anything for the spills, but we can clean up the issue where we materialize the same constant multiple times into the same register just to spill it.