search for: 20check

...on the aarch64 buildbot, but I can't reproduce the errors there. The failing test was present in SVN r351801 to r351810, in test/tools/llvm-objcopy/COFF/add-gnu-debuglink.test. The failing test looked like this: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/29113/steps/ninja%20check%201/logs/FAIL%3A%20LLVM%3A%3Aadd-gnu-debuglink.test http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/9987/steps/ninja%20check%201/logs/FAIL%3A%20LLVM%3A%3Aadd-gnu-debuglink.test Can someone with access to the buildbots (or similar systems) help reproducing the issue? The test outp...

Hi Dennis! clang-x64-ninja-win7 fails for some time on 1. UNRESOLVED: UBSan-Standalone-x86_64::log-path_test.cc <http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/4522/steps/ninja%20check%201/logs/UNRESOLVED%3A%20UBSan-Standalone-x86_64%3A%3Alog-path_test.cc> this masks other new test failuers (clang modules related). Could you have a look? Yaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachme...

...e actual bot [2] only tests the >> fuzzer itself over a well-known set of bugs in standard software (eg. >> Heartbleed [3] seems to be among them). > > Isn’t it this stage? http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fuzzer/builds/2755/steps/stage2%2Fasan%2Bassertions%20check-fuzzer/logs/stdio To me it looks like just the compilation and the unit+regression tests ("ninja check-fuzzer", not even depending on clang). It also completes in only 10 minutes, which is not a lot for fuzzing. Michael

Hi all, The blog entry [1] suggest that one of the buildbots constantly fuzzes clang and clang-format. However, the actual bot [2] only tests the fuzzer itself over a well-known set of bugs in standard software (eg. Heartbleed [3] seems to be among them). Has there actually ever been a buildbot that fuzzes clang/LLVM itself? Another (obvious?) fuzzing candidate would be the LLVM's bitcode

Bill, For some reason the llvm-symbolizer tests fail on ppc: http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/182/steps/ninja%20check%201/logs/stdio because it can't be started: /home/buildbots/ppc64le-clang-test/clang-ppc64le/stage1/./bin/llvm-symbolizer: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/buildbots/ppc64le-clang-test/clang-ppc64le/stage1/./bin/llvm-symbolizer) Alexey has reme...

...ks of "Machine code for function" for some of the failing tests. In other cases I'm getting what looks like a memory dump. I have the output from the latest run at the following URL if that helps: https://dmz-portal.mips.com/bb/builders/LLVM%20optimize%20install/builds/30/steps/make%20check-all/logs/stdio Brendan >> Brendan >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...here are two unexpected failures in the check-all (this check-all runs with self-build-clang): Failing Tests (2): Clang Tools :: clang-tidy/clang-tidy-diff.cpp Clang Tools :: clang-tidy/file-filter.cpp Last log: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/340/steps/ninja%20check%202/logs/stdio From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Thursday, April 23, 2015 12:27 To: Paweł Bylica Cc: Fedorova, Vera; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Buildbot for Windows native LLVM/Clang testing r235576 Window7 Visual C++ 2013 x64 just passed regression OK...

...ks of "Machine code for function" for some of the failing tests. In other cases I'm getting what looks like a memory dump. I have the output from the latest run at the following URL if that helps: https://dmz-portal.mips.com/bb/builders/LLVM%20optimize%20install/builds/30/steps/make%20check-all/logs/stdio Brendan >> Brendan >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev ___________________...

...ks of "Machine code for function" for some of the failing tests. In other cases I'm getting what looks like a memory dump. I have the output from the latest run at the following URL if that helps: https://dmz-portal.mips.com/bb/builders/LLVM%20optimize%20install/builds/30/steps/make%20check-all/logs/stdio Brendan >> Brendan >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev ___________________...

...s of "Machine code for function" for some of the failing tests. In other cases I'm getting what looks like a memory dump. I have the output from the latest run at the following URL if that helps: https://dmz-portal.mips.com/bb/builders/LLVM%20optimize%20install/builds/30/ steps/make%20check-all/logs/stdio Brendan >> Brendan >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev ___________________...

I've been reading the Google searches trying to understand how to tie together Adit 600 to Asterisk to provide 2 way service. I'm about blind from reading. I assume, the answer is using MGCP between the boxes. However, the examples I found don't really explain fully enough to know how to modify examples to work for me. I'll have in the ADIT with T1's. There is a CMG and

On Dec 12, 2011, at 6:26 PM, Brendan Kirby wrote: > As part of our automated testing, I'm running make check-all to watch > for failures. One of my builds uses the --enable-optimized option to > configure. When I build the latest trunk, I'm now seeing 18 failing > tests: > Clang :: Preprocessor/macro_paste_c_block_comment.c > LLVM ::

...patch and check-all passes without any issues (terminal capture at the end). Could there be something wrong with these bots? Do you have any idea what to try? === Build Failure === It was failing with this error ( http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/1493/steps/ninja%20check%201/logs/stdio ): Pass 'SanitizerCoverageModule' is not initialized. Verify if there is a pass dependency cycle. Required Passes: clang-3.9: /home/renato.golin/buildslave/clang-cmake-aarch64-full/llvm/lib/IR/LegacyPassManager.cpp:668: void llvm::PMTopLevelManager::schedulePass(llvm::Pass*)...

I agree, it is great. I have some regression tests (check-all) failures on Windows locally. Does the buildbot show the same? On Thu, Apr 23, 2015 at 11:16 AM Yaron Keren <yaron.keren at gmail.com> wrote: > That's great to hear! > > 2015-04-23 12:08 GMT+03:00 Fedorova, Vera <vera.fedorova at intel.com>: > >> Hi All, >> >> >> >> This is

...2] only tests the > > fuzzer itself over a well-known set of bugs in standard software (eg. > > Heartbleed [3] seems to be among them). > > Isn’t it this stage? http://lab.llvm.org:8011/build > ers/sanitizer-x86_64-linux-fuzzer/builds/2755/steps/ > stage2%2Fasan%2Bassertions%20check-fuzzer/logs/stdio > > > Has there actually ever been a > > buildbot that fuzzes clang/LLVM itself? > Yes, I used to run clang-fuzzer and clang-format-fuzzer on this bot, but not any more. The reason is simple -- the bot was always red (well, orange) and the bugs were never fixed....

This commit has added __hwasan_memset to compiler-rt: commit 749bd83b08b7239f5d18c4e3095183919c68eb30 Author: Eugene Leviant <eleviant at accesssoftek.com> Date: Thu Dec 20 09:10:03 2018 +0000 [HWASAN] Add support for memory intrinsics This is patch complements D55117 implementing __hwasan_mem* functions in runtime Differential revision: https://reviews.llvm.org/D55554

As part of our automated testing, I'm running make check-all to watch for failures. One of my builds uses the --enable-optimized option to configure. When I build the latest trunk, I'm now seeing 18 failing tests: Clang :: Preprocessor/macro_paste_c_block_comment.c LLVM :: CodeGen/ARM/2011-05-04-MultipleLandingPadSuccs.ll LLVM :: CodeGen/ARM/2011-11-14-EarlyClobber.ll LLVM