similar to: Please help: SVN is broken

On llvm-hexagon-elf, the two builds you mention actually came from two different machines. One of them fails consistently, the other one works. Since the builds are dispatched to whichever one is free, it may appear that they fail randomly. Let me see if I can fix it, if not, I'll complain to someone who can. -Krzysztof On 9/19/2017 8:33 PM, Zachary Turner via llvm-dev wrote: > Hi

So far two bots have complained about 2.7 (but have 2.6): http://bb.pgr.jp/builders/clang-i686-cygwin-RA-centos6/builds/12836/steps/configure/logs/stdio http://lab.llvm.org:8011/builders/llvm-s390x-linux1/builds/12002/steps/configure/logs/stdio Should we just upgrade those bots or reduce the requirement to 2.6? On 12 December 2014 at 06:41, Dan Liew <dan at su-root.co.uk> wrote: > +1

Folks, I'm not sure what happened, but some commit in this build made Clang run forever on ARM: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/2203 The missing commits are to the sanitizers and they are not even checked out on this bot, so I don't think it has anything to do with that. It's also unlikely to be something on the Hexagon back-end, since all changes are

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

Should "lit :: shtest-format.py" (from check-lit) be marked unsupported on PS4? It seems flakey there. This evening, it failed on my commit, r337514, and I'm fairly confident it wasn't my commit's fault. Then it recovered on the next commit. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/33502

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

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

FWIW, I've seen it fail on some of my commits too, but I don't remember whether it was on the PS4 bot exclusively or not. Anyway, my understanding is that this test shouldn't inherently have different behaviour on PS4 specifically, but I could be mistaken. I suspect it's something more general to do with the configuration of the bot. James On 20 July 2018 at 03:52, Justin Bogner

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

Hi all, I tried to use std::to_string somewhere and one of the bots yelled at me [1] because it couldn't find it. Searching through the mailing lists reveals a long stream of fixup patches trying to avoid std::to_string, but there are uses of it in tree in the AVR and Hexagon backends, libFuzzer and the Gold plugin. I can only imagine they got away with it because the particular bots that

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

It works for me: ------ Build started: Project: LLVMHexagonCodeGen, Configuration: RelWithDebInfo Win32 ------ cl : Command line warning D9002: ignoring unknown option '/Zc:inline' HexagonFrameLowering.cpp ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== Here's the info from the "about" window: Microsoft Visual Studio Professional 2013

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 2/12/2016 9:47 PM, Vince Harron wrote: > Are you building LLDB? Im guessing that is where the failure is I'm building LLVM. The failure in the buildbot happens when compiling HexagonFrameLowering.cpp: ---------- FAILED: C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe /nologo /TP /DWIN32 /D_WINDOWS /W4 -wd4141 -wd4146 -wd4180 -wd4244 -wd4258 -wd4267 -wd4291 -wd4345 -wd4351 -wd4355 -wd4456

It looks like my Metadata/Value split broke the hexagon bot [1], but I can't figure out why. Is there anyone that can help me diagnose the problem? [1]: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/13434 All the tests are crashing in the same way; looks like a double-free? (In the meantime, I'll keep trying to find the problem by inspection...)

r223478 seems to be responsible for PR21770: http://llvm.org/bugs/show_bug.cgi?id=21770 On Fri, Dec 5, 2014 at 3:10 PM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > I'm not sure if it helps but the clang builder for mips has been dying of > timeouts since > http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/389 which only > has one commit in the blamelist

On Tue, 29 Jan 2019 at 21:05, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The patch is about ready to land, which means any older compiler will soft-error (which you can turn off with LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN). I think we should then cherry-pick the patch to the LLVM 8 branch. > > The last remaining issue are the buildbots. I audited *all* bots in

I'm fairly sure the problem is that we still support building with gcc 4.8.x, and that version of gcc did not have std::to_string. It is not just an NDK issue. -Hal On 05/17/2017 06:05 AM, Pavel Labath via llvm-dev wrote: > Hi Diana, > > I am responsible for that bot, and probably a great number of those fixups. > > The root of the problem is that android NDK comes with a

As Davide suggests, most likely it's a bot software installation snafu. But the simpler sed script works perfectly, and I'll do that for now. I had understood that LLVM expected people to install GnuWin32, but maybe it's not sufficiently well specified about versions and whatnot. --paulr > -----Original Message----- > From: davide.italiano at gmail.com [mailto:davide.italiano