similar to: svn problem checking out test suite

You likely have an http proxy in your network which is blocking RTF files in case they are viruses or something. You might try https, if you're lucky it will bypass your proxy. On Fri, Jan 26, 2018 at 11:13 AM, Bill Seurer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I updated one of the powerpc64 lnt buildbot machines to a new OS release > and the buildbot started failing

It could be. I am not sure what is running upstream of the affected machines though it is odd that only those using late releases of svn are affected. I did try using https for a by-hand checkout and that worked but I don't know how to change the buildbots to use https instead of http. I sent a note off to the person who runs the buildbot master. On 01/26/2018 02:22 PM, Don Hinton

There are lots and lots of .rtf files and it is just these 3 and just on certain systems. On 01/26/2018 11:41 AM, James Y Knight wrote: > You likely have an http proxy in your network which is blocking RTF > files in case they are viruses or something. You might try https, if > you're lucky it will bypass your proxy. -- -Bill Seurer

Not sure if this applies, but at least one antivirus engine thinks MultiSource/Applications/ClamAV/inputs/rtf-test/docCLAMexe.rtf is malicious. https://www.hybrid-analysis.com/sample/bba4eab51c27a6ffbd86bf870048da 1902cc7235a4de49cf30208906dac50f85?environmentId=100 On Fri, Jan 26, 2018 at 11:02 AM, Bill Seurer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > There are lots and

Hi Bill, I believe you just need to update the urls in the various .py files at http://llvm.org/svn/llvm-project/zorg/trunk/zorg/buildbot/builders/ <http://llvm.org/svn/llvm-project/zorg/trunk/zorg/buildbot/builders/>. After that, the buildmaster will need restarting. Hopefully all the bots support https, but it can be made optional if that's not the case. > On 26 Jan 2018, at

I looked at this a bit a while back when you first asked but I didn't see anything obviously wrong. Benjamin, at least one of the referenced failures was on BE powerpc64. I don't remember if that one (http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/4883) failed on stage 1 or 2 and the results pages are no longer available. BTW, I tried testing the same revision many

On 2 April 2013 21:20, Török Edwin <edwin+ml-debian at etorok.net> wrote: > You can pass all the filenames from the inputs/ directory directly on the > command-line, instead of specifying -r inputs/. > That way the order of scanning will be exactly the one specified on the > command-line. > Hum, I think I can fix that with Make... --renato -------------- next part

On 04/02/2013 11:06 PM, Daniel Dunbar wrote: > On Tue, Apr 2, 2013 at 11:46 AM, Renato Golin <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> wrote: > > On 2 April 2013 19:20, Daniel Dunbar <daniel at zuster.org <mailto:daniel at zuster.org>> wrote: > > What is it that makes the output of the program asynchronous? The output is

This just failed again: http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/1579 Bill, could you take a look at this? This is like the 3rd time I've been incorrectly pinged by this buildbot due to this issue. -- Sean Silva On Mon, Jun 13, 2016 at 8:07 PM, Sean Silva <chisophugis at gmail.com> wrote: > Thanks for taking a look. The flaky ASan test failure in the

Hi Torok, I've used a hard-coded list on the input parameter and still got some output (slightly) scrambled between two different bots... INPUT = $(PROJ_SRC_DIR)/inputs/clam.cab \ $(PROJ_SRC_DIR)/inputs/clamdoc.tar.gz \ $(PROJ_SRC_DIR)/inputs/clam.exe \ $(PROJ_SRC_DIR)/inputs/clam.exe.bz2 \ $(PROJ_SRC_DIR)/inputs/clam-v2.rar \

It appears that lnt has the capability to run the SPEC2000/2006/2017(maybe) tests from looking at the options and from poking around in the mailing list archives. Or does it? I experimented a bit and cannot get it to work right. However, it isn't really documented anywhere so maybe I didn't set it up properly. Plus there's all the mention of llvmgcc... So is anyone doing

I updated a powerpc64 be system from fedora 25 (glibc 2.24) to fedora 26 (glibc 2.25) and several test cases started failing that deal with dynamic thread local storage. Failing Tests (3): LeakSanitizer-AddressSanitizer-powerpc64 :: TestCases/Linux/use_tls_dynamic.cc LeakSanitizer-Standalone-powerpc64 :: TestCases/Linux/use_tls_dynamic.cc MemorySanitizer-POWERPC64 ::

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

Jay, do you have a PowerPC64 target? If so, could you please check attached patch on PPC box? This is a draft patch, but it would be nice to make sure that we are moving to right direction here. Thanks, -Maxim On 18/11/15 00:12, Jay Foad wrote: >>> Currently test/asan/TestCases/alloca_vla_interact.cc is XFAILed for >>> powerpc64. I've had a look at why it

Hi! Sorry for delay, just returned from vacation. On 12/11/15 23:44, Kostya Serebryany via llvm-dev wrote: > +Maxim and Yuri, as I think this is their code. > > On Thu, Nov 12, 2015 at 3:02 AM, Jay Foad <jay.foad at gmail.com > <mailto:jay.foad at gmail.com>> wrote: > > (Resending with the correct mailing list address.) > > Hi, > > Currently

Hi all, I compiled 64-bit R on an Apple Mac G5 running OS X, but it failed make check. Simon Urbanek suggested I post results to R-devel. > On Nov 6, 2007, at 10:23 PM, Steven McKinney wrote: > > > Hi Simon, > > > > Would you be able to give more guidance on how to compile 64-bit > > libiconv for Tiger, > > You can get the sources from Apple and compile

Hi, I just filed a bug because LLVM's test suite includes a virus. This is not normally a problem on Unix (not even Linux), but as everyone know, Windows is so vulnerable to vira, that Windows users have to have an antivirus solution installed. The problem is that the virus in: projects/test-suite/MultiSource/Applicaations/ClamAV/inputs/rtf-test/rtf1.rtf BREAKS the SVN pull of the LLVM

In LowerGET_DYNAMIC_AREA_OFFSET() you're calling MFI->getMaxCallFrameSize(), but it looks like that doesn't return useful information until after the PrologEpilogInserter's PEI::calculateCallsInformation() has run. So maybe the lowering has to be done as part of frame index elimination? (I'm not too familiar with this code.) Jay. On 23 November 2015 at 13:07, Jay Foad

(Resending with the correct mailing list address.) Hi, Currently test/asan/TestCases/alloca_vla_interact.cc is XFAILed for powerpc64. I've had a look at why it doesn't work. I think the only problem is in the call to __asan_allocas_unpoison that is inserted at the end of the "for" loop (just before a stackrestore instruction). The call function is created something like this

Chris Lattner wrote: > One way to do this is to add a "cut down" version of the app to the > test suite. I disabled optional features in clamav-config.h > >> 2. GPL license. Chris? > > Any open source license that allows unrestricted redistribution is > fine in llvm-test Ok, I have created a script that automatically checks out ClamAV 0.92-stable source code