similar to: Self-hosting bots noise

On Nov 9, 2015, at 11:42 AM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On Mon, Nov 9, 2015 at 4:32 AM, Renato Golin <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> wrote: > Hi David/Galina, > > FYI, I found one big reason why self-hosting bots fail long after the > offending commit is tested: dirty builds. >

On Tue, Sep 1, 2020 at 3:57 PM David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, Sep 1, 2020 at 12:42 PM Nico Weber <thakis at chromium.org> wrote: > >> On Tue, Sep 1, 2020 at 3:32 PM David Blaikie <dblaikie at gmail.com> wrote: >> >>> On Tue, Sep 1, 2020 at 12:07 PM Nico Weber via cfe-dev < >>> cfe-dev at lists.llvm.org>

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

Hello all, I broke the build, but I did not receive any blame email about it. I have a feeling the blame emails are not working. Is anyone experiencing the same thing? Could it be related to the last-week master restart (which seems to have reset build numbers as well)? regards, pl

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

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

Since this is causing all of our internal CI to back up, could you please revert your two changes, so we can make sure that they were actually responsible, and can work on a fix for this? Let me know how we can help investigate this. -- adrian > On Nov 13, 2017, at 3:25 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The first build where a test fails with

Yes I can reproduce this locally. It looks like we are not passing an -isysroot (pointing to the SDK) to clang but it isn’t clear what lit magic would expand this. -- adrian > On Nov 13, 2017, at 3:30 PM, Zachary Turner <zturner at google.com> wrote: > > Yea I'm preparing a revert right now. Does it happen for you when you run debuginfo-tests locally? > > On Mon, Nov

On the other hand this file hasn't changed recently, but I have no way to test this as it uses the LLDB code path, which only runs on OSX. On Mon, Nov 13, 2017 at 3:19 PM Zachary Turner <zturner at google.com> wrote: > I might be missing something, but this doesn't look like me? > > >

Yea I also just found it. Try adding this code in the bottom of debuginfo-tests/lit.cfg.py lit.util.usePlatformSdkOnDarwin(config, lit_config) On Mon, Nov 13, 2017 at 4:38 PM Adrian Prantl <aprantl at apple.com> wrote: > Ha! Found it. *Somebody* is setting an SDKROOT variable in the > environment. Can you find the code that would do this? > > — adrian > > > On Nov

Great! It's close to the end of the day, so I'll submit tomorrow to make sure everything has a chance to go fully green again to ensure I get failure emails if it breaks. On Mon, Nov 13, 2017 at 4:43 PM Adrian Prantl <aprantl at apple.com> wrote: > I can confirm that that fixes the issue! > > — adrian > > > On Nov 13, 2017, at 4:38 PM, Zachary Turner <zturner

Hi Zackary, Did you see my followup to you cfe-commits rollback: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171120/210212.html I think you can just remove the change to cfe/trunk/test/CMakeLists.txt and it should work just fine. hth... don On Tue, Nov 21, 2017 at 12:00 PM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Just an update, > > At

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

It looks like the bots are still red? — Adrian > On Nov 10, 2017, at 3:14 PM, Zachary Turner <zturner at google.com> wrote: > > Wasn't quite fixed, but it got a lot further this time. This time there was still an issue in the test_debuginfo.pl <http://test_debuginfo.pl/> script regarding a hardcoded path to the llgdb.py script. I think I never encountered this locally

It looks like this broke green dragon: http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40383/console llvm-lit: /Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/projects/libcxx/utils/libcxx/test/config.py:173: note: Adding environment variables: {'DYLD_LIBRARY_PATH': '/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/./lib',

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

> On Nov 10, 2017, at 2:50 PM, Zachary Turner <zturner at google.com> wrote: > > I checked in a fix for that already, sorry for the trouble. I’m waiting for it to cycle awesome. Thanks! -- adrian > On Fri, Nov 10, 2017 at 2:49 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > It looks like this broke green dragon: > >

I'm working on bringing up a buildbot in the LLVM lab that would run the GCC and GDB DejaGNU tests. The current problem I'm running into is shown here: http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb-gcc/builds/323/steps/install.clang.stage1/logs/stdio When the buildbot attempts to "make install" the system 'strip' binary fails while attempting to strip the

I sorta enjoy debugging stuff like this, so if you don't mind, I'll dig into it once I get a chance -- traveling so, my access is a bit sketchy right now. I'll see if I can grab the logs and let you know if I find anything interesting. On Tue, Nov 21, 2017 at 7:04 PM, Zachary Turner <zturner at google.com> wrote: > That change was added specifically to workaround a failure

Hi Galina, It seems that all the bots (buildbots and green dragon) are not processing new SVN revisions since the llvm.org IP address update. It seems we have gotten no new revs since Noon today? Perhaps the SVN mirror is not picking up new commits?