similar to: AArch64 testsuite buildbots timeout

You're not the only one Hans, my VMs have started crashing my host OS :) Fedora and OpenSUSE look good, binaries uploaded. On Sat, Dec 13, 2014 at 12:06 PM, Hans Wennborg <hans at chromium.org> wrote: > > On Thu, Dec 11, 2014 at 5:26 PM, Tom Stellard <tom at stellard.net> wrote: > > Hi, > > > > 3.5.1-rc1 has been tagged, so it is time to begin testing. We

On 13 December 2014 at 16:50, Renato Golin <renato.golin at linaro.org> wrote: > Same here... ARMv7 is already up and tested, AArch64 is proving a bit > more complicated due to old libstdc++ on my box. I'm working on it. I'm seeing one error on AArch64's test-suite: SingleSource/UnitTests/Vector/AArch64/aarch64_neon_intrinsics.c:154979:16: warning: implicit declaration of

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

Hi, Please suggest a method to answer below questions: Factory_ID Factory_Location Factory_Size Total_Sample Good_Sample Fair_Sample Bad_Sample ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 1 City_A

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 *

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

Hi LLVM Developer Team, My name is Mark Babatunde and I'm a third year computer science student at the University of Pittsburgh. I was looking at the potential list of projects and the project regarding adding support for batch-testing to the LLDB testsuite caught my interest. I was wondering how I can get started and if I can get in contact with Jim Ingham. Best, Mark Mark Babatunde

Evan Cheng wrote: > We always welcome more tests. But it looks like there are two issues > here. > > 1. The autoconf requirement. Is it possible to get one configuration > working without the need for autoconf? > I could make an clamav-config.h that should work if compiled with llvm-gcc. Can I assume <endian.h> exists on all your platforms? [or how else can I detect

Török Edwin wrote: > Attaching all files. Let me know if you want to upload the entire > package somewhere. > [...] > Please provide feedback on the scripts, and Makefile. > [...] > What are the next steps required to add it to the testsuite Is there any chance for this to go in before the code freeze, or do you prefer to add it after? Best regards, --Edwin

>> 2. filterdiff.sh uses sed -re. This causes a problem on Mac OS X >> where >> -E means using extended regular expression, not -r. >> Can this be changed? >> > > I'm not really familiar with sed's non-extended regular expression > syntax, I'll have to read its info page. > I can do that if you decide to keep filterdiff.sh, see below Why not

> Just my two cents. From time to time I'm testing LLVM via > compiling & running such big beasts as Qt and Mozilla. Also, > at 2.0 time I tried to compile & test bunch of software from > KDE and many others. I tried to compile the 3D game engine "darkplaces" with llvm-gcc 4.2, but the produced binary didn't work. However, I didn't find out how debug

I would like to see: (1) LLVM testsuite run every night for all targets, target variants and operating systems, for example by using an emulator to emulate targets for which the hardware is not available. The gcc project has a compile farm which might be usable for this, but we would need to ask them if it is ok. (2) Likewise for the gcc testsuite, with results emailed to the nightly test

On Mar 20, 2008, at 10:08 AM, Dale Johannesen wrote: > I'm seeing ~100 new failures in the gcc testsuite due to the test > file being doubled or tripled, as below. This appears to affect > only files that were newly imported from gcc-4.2 in the recent > merge. Does anybody have an idea for how to mechanize fixing these > (I doubt you can count on the APPLE LOCAL

These should be fixed now. Sorry for the mess. -bw On Mar 20, 2008, at 10:08 AM, Dale Johannesen wrote: > I'm seeing ~100 new failures in the gcc testsuite due to the test > file being doubled or tripled, as below. This appears to affect > only files that were newly imported from gcc-4.2 in the recent > merge. Does anybody have an idea for how to mechanize fixing these

While on the subject of the testsuite, some random thoughts: - show how test results changed from one week and one month ago, and compared to the last release, rather than just comparing with the previous run as now. Good for spotting trends. - fix the testsuite so that buildlogs are really available: I occasionally see that a nightly tester failed the build, and in the message it gives a url

Hi, I'm trying to run tests from the LLVM testsuite (from http://llvm.org/svn/llvm-project/test-suite/trunk) using an already installed LLVM compiler. To instruct the testsuite's Makefiles where the LLVM tools live, I use the LLVMTOOLCURRENT Makefile variable: make LLVMTOOLCURRENT=$PATH_TO_LLVM_INSTALL_DIR TEST=nightly report Is there a cleaner way of achieving this? Thanks in advance!

Török Edwin <edwintorok at gmail.com> writes: > I don't see anything wrong with FileCheck either. > > However looks here, that .bc file is in the *source* tree, not the obj tree: > not llvm-dis < /ptmp/dag/llvm-project.official/llvm/trunk/test/Bitcode/null-type.ll.bc > /dev/null |& grep "Invalid MODULE_CODE_FUNCTION record" I think that's there from

greened at obbligato.org (David A. Greene) writes: > Any hints on how to make absolute paths stick? Ok, I finally got that to work. I'm running experiments now. -Dave

greened at obbligato.org (David A. Greene) writes: > greened at obbligato.org (David A. Greene) writes: > >> Any hints on how to make absolute paths stick? > > Ok, I finally got that to work. I'm running experiments now. After fixing a few Python bugs in my code, I now have everything passing. Prepending the path to the tools being tested fixed all the problems. I will

I just tried cmake for the first time and it mostly worked. I had been using autotools to configure. With cmake configure environment when I try to do: make TESTSUITE=CodeGen/mblaze check it runs the whole test suite. Under autotools it would just run the mblaze tests. Is there an equivalent command in a camke configured environment or is this broken? I know nothing about cmake so I'm