similar to: Builder lld-x86_64-win7​ is back

Reid said that he has disabled non-x86-64 backends for the clang/win64 buildbot, so maybe this is the first time for us to see these warnings. But all of them seem to be easily fixable, so why don't we do that. On Tue, Feb 9, 2016 at 10:49 AM, Rafael Espíndola < llvm-commits at lists.llvm.org> wrote: > Most of the warnings are actually in LLVM code. Any reason we don't > see

Tried to fix the warning, and I'm not now sure if the warning makes sense. These "'~': zero extending '<smaller integer type>' to 'int64_t' of greater size" warning may be annoying as it is issued for code like "int64_t x = ~<some-int32_t-var>". Probably we should disable the warning instead? On Tue, Feb 9, 2016 at 11:15 AM, Rafael

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

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

Thanks a lot for setting this up! By using the "mean as aggregation" option one can see the noise in the results better: http://lnt.llvm.org/db_default/v4/link/graph?switch_min_mean=yes&moving_window_size=10&plot.9=1.9.7&submit=Update There are a few benchmarknig tips in https://www.llvm.org/docs/Benchmarking.html. For example, from looking at

Hello build bot owners! The staging master is ready. Please feel free to use it to make sure your bots would work well with the monorepo and github. The following builders could be configured to build monorepo: * clang-atom-d525-fedora-rel * clang-native-arm-lnt-perf * clang-cmake-armv7-lnt * clang-cmake-armv7-selfhost-neon * clang-cmake-armv7-quick * clang-cmake-armv7-global-isel *

>Hello everyone, > >I have added a new public LLD performance builder at >http://lab.llvm.org:8011/builders/lld-perf-testsuite. >It builds LLVM and LLD by the latest releaed Clang and runs a set of >perfromance tests. > >The builder is reliable. Please pay attention on the failures. > >The performance statistics are here:

Hello George, Sorry, somehow hit a send button too soon. Please ignore the previous e-mail. The bot does 10 runs for each of the benchmarks (those dots in the logs are meaningful). We can increase the number of runs if proven that this would significantly increase the accuracy. I didn't see the increase in accuracy when have been staging the bot, which would justify the extra time and larger

Hello everyone, We are in the middle of porting the majority of zorg to GitHub/monorepo. The following build factories will be ported and if you use one of those for your bots, you are all covered: * ClangBuilder.getClangCMakeBuildFactory (31 bots) * ClangBuilder.getClangCMakeGCSBuildFactory (2 bots) * LibcxxAndAbiBuilder (23 bots) * SphinxDocsBuilder (7 bots) * UnifiedTreeBuilder (11

Galina Kistanova <gkistanova at gmail.com> writes: > Yep. They are still clustered. > >> Is there anything else running on the machine while the tests are run? > > Not much. The usual buildslave stuff - buildbot, ssh server, some light > network services, snmp client, but that's pretty much it. 20 hardware > threads are designated for this. > > The test

Galina Kistanova <gkistanova at gmail.com> writes: > Hello Rafael, > >> It seems the produced lld binary is not being statically linked. > > Hm. It should. But it seems couple config params are missing. Fixed. Thanks > for catching this! > >> Is lld-speed-test in a tmpfs? > > Correct. > All the benchmarking tips from

Hello everyone, LLVM buildmaster is back to work. Two slaves remain off for now as they produce a lot of warnings and their log files are way too big. The next builds have full logs available. Hope this helps to fix this issue: http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/8716 http://lab.llvm.org:8011/builders/clang-with-thin-lto-windows/builds/2645 Thanks Galina

> The HT siblings are disabled, right? Correct. > It is probably a good idea to experiment with disabling swap and having > a single cpu in the shield group. Yep. This is what I'm in the middle of. So far I see that it seems the scheduler is keep running on shielded cores no matter what. Even if there is only 1 core in the shield. Thanks Galina On Wed, Feb 28, 2018 at 11:36

Hello Rafael, > It seems the produced lld binary is not being statically linked. Hm. It should. But it seems couple config params are missing. Fixed. Thanks for catching this! > Is lld-speed-test in a tmpfs? Correct. All the benchmarking tips from https://www.llvm.org/docs/Benchmarking.html have been applied to that bot. > Is lld-benchmark.py a copy of lld/utils/benchmark.py?

On Tue, Feb 9, 2016 at 3:03 PM, Joerg Sonnenberger via llvm-commits < llvm-commits at lists.llvm.org> wrote: > On Tue, Feb 09, 2016 at 02:40:06PM -0800, Rui Ueyama via llvm-commits > wrote: > > Tried to fix the warning, and I'm not now sure if the warning makes > sense. > > These "'~': zero extending '<smaller integer type>' to

Hi Rafael, Thanks for mentioning this. It should be running as root, but I'll double check anyway. Thanks Galina On Mon, Mar 26, 2018 at 10:47 AM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Galina Kistanova <gkistanova at gmail.com> writes: > > > Disabling swap and having a single CPU in the shield group didn't change > > much,

Thanks, Galina. It doesn't explain why the test worked on some bots but not this one, but Justin's workaround is okay with me. --paulr From: Galina Kistanova [mailto:gkistanova at gmail.com] Sent: Thursday, November 09, 2017 10:09 AM To: Robinson, Paul Cc: Davide Italiano; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Problem with 'sed' on one Windows bot? There is nothing

The problem remains after the buildmaster restart. Thanks Galina -----Original Message----- From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Tuesday, December 11, 2012 11:42 AM To: Galina Kistanova Cc: Duncan Sands; llvm-lab-wg at lists.minormatter.com; Galina Kistanova; llvmdev at cs.uiuc.edu Subject: Re: [llvm-lab-wg] FNT testers reporting success even though they failed On Tue,

Disabling swap and having a single CPU in the shield group didn't change much, besides cpu-migrations and context-switches, which now are 0 obviously. That clustering remains the same. It is also stable to the number of runs (I have changed the test to run 20 times in the middle of that range on the right). http://lnt.llvm.org/db_default/v4/link/graph?highlight_run=426&plot.9=1.9.6

Hello everyone, It might make sense to start from rebooting the buildmaster, just to make sure everything is all right on this end. Yesterday I have tried to apply the latest changes from zorg and some of them are broken. Theoretically, checkconfig shouldn't affect the working instance, but the reality could be different... I planned to rollback to the last known-to-be-good revision and