similar to: Test-suite bots red because of missing import

Hi, There was a new Python setuptools release (36.0.0) today, that caused this compatibility issue. The suggestion to stop breaking the builds is to add a static setuptools version on lnt's requirements.client.txt. The latest known compatible version is 35.0.2. I have tested it building a LNT sandbox and it seems to works. setuptools==35.0.2 I'll create a bug on LNT so we can

So, in the end looks like this setuptools 36 was deleted from pypi. There is an issue [1] open on setuptools. I can confirm by trying to force to install this version: $ pip install setuptools==36.0.0 Collecting setuptools==36.0.0 Could not find a version that satisfies the requirement setuptools==36.0.0 (from versions:<many version numbers>) No matching distribution found for

Hi, It seems the problem is that the bot is updating llvm.src, but trying to build from llvm. Galina, it looks like this is related to your recent changes to zorg, you probably missed a spot somewhere and I can't find it on a first glance. Could you have a look? Thanks, Diana On 5 September 2016 at 12:01, Diana Picus <diana.picus at linaro.org> wrote: > Hi Nico, > > Thanks

Hi, many of the bots on http://lab.llvm.org:8011/console don't do anything in their compile phase, even if they should. For example, these bots all don't do anything in their compile phase in any builds, even if they should: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/ http://lab.llvm.org:8011/builders/clang-ppc64be-linux

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

Hi Galina, It seems that our libcxx bots are now triggering builds for any changes to llvm: http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434 Should I file a bug report for this? Thanks, Diana On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits <cfe-commits at lists.llvm.org> wrote: > > Hello everyone, > > The staging master is

Great! I expect I'll be able to cut it down further once I start fusing these smaller state-machines together. Before that, I'll re-order the patches that went into that diff so that I don't have to re-commit the regression before fixing it. > On 31 May 2017, at 13:48, Diana Picus <diana.picus at linaro.org> wrote: > > Hi, > > This runs in: > real

Is https://reviews.llvm.org/differential/diff/100829/ replacement for r303341? If so LGTM. r303542 msan AArch64InstructionSelector.cpp: 1m17.209s r303542+diff/100829/ <https://reviews.llvm.org/differential/diff/100829/> msan AArch64InstructionSelector.cpp: 1m24.724s On Wed, May 31, 2017 at 6:13 AM, Daniel Sanders <daniel_l_sanders at apple.com> wrote: > Great! I expect

On 18 May 2017 at 19:09, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Diana, > >> On May 18, 2017, at 1:15 AM, Diana Picus <diana.picus at linaro.org> wrote: >> >> On 18 May 2017 at 09:06, Kristof Beyls <Kristof.Beyls at arm.com> wrote: >>> I think Diana found that when enabling r299283, the bootstrap failed with >>> llvm-tblgen

On 18 May 2017 at 09:06, Kristof Beyls <Kristof.Beyls at arm.com> wrote: > I think Diana found that when enabling r299283, the bootstrap failed with > llvm-tblgen segfaulting. > So there clearly is some work required there. Indeed. @Quentin, what is the status of that patch? Have you been working on it since then? Should I investigate the segfault more and send you a reproducer?

Turns out it really is a GlobalISel issue - we eat up too much stack space because all the constants used in the switches are stored on the stack. We need to fix this somehow before changing the default. I'll try to give it a run with Quentin's r299283 on top to see if it helps. Cheers, Diana On 15 May 2017 at 09:38, Diana Picus <diana.picus at linaro.org> wrote: > Got another

Hi Quentin, I actually did a run with -mllvm -optimize-regalloc -mllvm -regalloc=greedy over the weekend and the test does pass with that. Haven't measured the compile time though. Cheers, Diana On 19 May 2017 at 19:06, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Diana, > > On May 19, 2017, at 1:33 AM, Diana Picus <diana.picus at linaro.org> wrote: > >

Hi Diana and Vitaly, Could you give https://reviews.llvm.org/differential/diff/100829/ <https://reviews.llvm.org/differential/diff/100829/> a try? When measuring the compile of AArch64InstructionSelector.cpp.o with asan enabled and running under instruments's Allocation profiler, my machine reports that the cumulative memory allocations is down to ~3.5GB (was ~10GB), the number of

Hello all bots owners, As all of you know we move to github monorepo very soon now. We are actively working on the buildbot to prepare a solution to switch from SVN to github when time comes. It would require some activity on your bots. At this point it is clear that you would need to * Make sure you have reasonably recent version of git installed and in the system path for the buildbot

Agreed. That was probably just luck before :) -eric On Fri, May 12, 2017 at 5:22 AM Diana Picus via llvm-dev < llvm-dev at lists.llvm.org> wrote: > It turns out that can be fixed by adding -lm to the link line, so I > will probably convert it into a test-suite bug. > > I don't suppose it's crucial to handle the fabs intrinsic nicely at -O0. > > On 12 May 2017 at

Hi Daniel, I did your experiment on a TK1 machine (same as the bots) and for r303258 I get: real 18m28.882s user 35m37.091s sys 0m44.726s and for r303259: real 50m52.048s user 88m25.473s sys 0m46.548s If I can help investigate, please let me know, otherwise we can just try your fixes and see how they affect compilation time. Thanks, Diana On 22 May 2017 at 10:49, Daniel

Hi all, We had some internal discussions about flipping the default for O0 and we concluded that we wanted to postpone it. *** Why Is That? *** We don’t want to send the wrong message that GlobalISel’s design is set in stone and ready for broader adoption. In particular, 1. The APIs are still evolving and can still possibly change significantly 2. The TableGen backend to reuse the existing SD

Thanks for trying that patch. I agree that 34 mins still isn't good enough but we're heading in the right direction. Changing the partitioning predicate to the instruction opcode rather than the number of operands in the top-level instruction will hopefully cut it down further. I also have a patch that shaves a small amount off of the compile-time by replacing the various

Great, good to know it's not just a problem with our bot. Thanks! On 28 August 2017 at 16:24, Chris Matthews <cmatthews5 at apple.com> wrote: > Hi Diana, > > I have seen that issue on some other bots too. I will fix it this week. It is something about how MySQL treats character encodings differently than Postgres. We are checking for the value in the table beforehand, and this

Nope, no sanitizers. On 22 May 2017 at 11:38, Daniel Sanders <daniel_l_sanders at apple.com> wrote: > Is that with -fsanitize=memory too? > > I'm currently building ToT with r303258 reverted. Once that's done I'll commit the revert and start investigating fixes. > >> On 22 May 2017, at 10:22, Diana Picus <diana.picus at linaro.org> wrote: >>