similar to: [LLVMdev] MiBench

John, Just get it restored from backups -- they don't take long to do it and it will preserve the logs. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Jan 9, 2007, at 5:23 PM, John Criswell wrote: > Dear All, > > Please don't kill me. > > I've accidentally removed the directory >

All, Commits aren't taking right now because apparently Zion is out of disk space: cvs commit utils/findmisopt Checking in utils/findmisopt; /var/cvs/llvm/llvm/utils/findmisopt,v <-- findmisopt new revision: 1.9; previous revision: 1.8 done Insufficient disk space; try again later Insufficient disk space; try again later returntosender: cannot select queue for llvm Insufficient disk

How big was that log file? If we are running close to the limit, I can just buy a new disk for zion. Other suggestions welcome. --Vikram On Nov 25, 2006, at 12:38 AM, John T. Criswell wrote: > Reid Spencer wrote: > > 1) It appears that the only problem was with sending email to the > llvm-commits list; any files commited to the repository should be > commited. > >

Reid Spencer wrote: 1) It appears that the only problem was with sending email to the llvm-commits list; any files commited to the repository should be commited. 2) The web server error log filled up /var/log, preventing the CVS commit script from sending email. The Apache error log was filled with entries like this: [client 219.140.157.109] PHP Notice: Undefined offset: 1 in

On Thu, 24 Jun 2004, Vladimir Merzliakov wrote: > > Are you using the NightlyTest.pl file? To run the tester I don't use > > gmake directly at all. Instead, I have this in my crontab: > > > > 5 3 * * * > LLVM_LIB_SEARCH_PATH=/home/vadve/lattner/local/x86/llvm-gcc/bytecode-libs > $HOME/llvm/utils/NightlyTest.pl -parallel -enable-linscan >

> Are you using the NightlyTest.pl file? To run the tester I don't use > gmake directly at all. Instead, I have this in my crontab: > > 5 3 * * * LLVM_LIB_SEARCH_PATH=/home/vadve/lattner/local/x86/llvm-gcc/bytecode-libs $HOME/llvm/utils/NightlyTest.pl -parallel -enable-linscan /home/vadve/shared/PublicCVS $HOME/buildtest-X86 $HOME/cvs/testresults-X86 > > When run like this,

On Thu, 24 Jun 2004, Vladimir Merzliakov wrote: > At this moment I use > "gmake TEST=nightly" command line to run night tester > > What I must specific and where to disable SPEC run (i don't have it) I think that it's currently a bug that this does not automatically happen. > I known about new NightlyTest.pl option: -noexternals > But what I must do for

Chris Lattner wrote: > On Fri, 29 Jun 2007, John Criswell wrote: > >> The LLVM web server is up and running, but we're still working on some >> subversion configuration issues. The server may go up and down >> intermittently as we try configuration changes over the next half hour. >> > > Apparently someone clobbered

Hello list, I found two tests of MiBench in test-suite are NOT tested correctly. #1. test-suite/MultiSource/Benchmarks/MiBench/office-ispell #2. test-suite/MultiSource/Benchmarks/MiBench/telecomm-adpcm Case #1, the test program outputs an error message, 'Illegal format hash table'. And test is NOT executed! Case #2, the test program hangs in somewhere and NEVER return. The test script,

> On Thu, 24 Jun 2004, Vladimir Merzliakov wrote: > > > At this moment I use > > "gmake TEST=nightly" command line to run night tester > > > > What I must specific and where to disable SPEC run (i don't have it) > > I think that it's currently a bug that this does not automatically happen. > > > I known about new NightlyTest.pl option:

At this moment I use "gmake TEST=nightly" command line to run night tester What I must specific and where to disable SPEC run (i don't have it) I known about new NightlyTest.pl option: -noexternals But what I must do for enable it Vladimir

Hi, I get the following failures when I run the test-suite on linux (Ubuntu 12.04) using LNT (lnt runtest nt ...): (all are execution failures) MultiSource/Applications/Burg MultiSource/Applications/ClamAV MultiSource/Applications/lemon MultiSource/Applications/obsequi MultiSource/Benchmarks/MiBench/automotive-bitcount

On Fri, 29 Jun 2007, John Criswell wrote: > The LLVM web server is up and running, but we're still working on some > subversion configuration issues. The server may go up and down > intermittently as we try configuration changes over the next half hour. Apparently someone clobbered /home/vadve/shared/PublicCVS/CVSROOT/passwd. This prevents anyone with no account on zion from

On Fri, 29 Jun 2007, John Criswell wrote: > Chris Lattner wrote: >> On Fri, 29 Jun 2007, John Criswell wrote: >>> The LLVM web server is up and running, but we're still working on some >>> subversion configuration issues. The server may go up and down >>> intermittently as we try configuration changes over the next half hour. >>> >> >>

There is almost certainly a bug in lnt or the makefiles. I changed the body of Burg main to the following: + printf("Hello World\n"); + return 0; I re-ran the test-suite again and got the following errors: --- Tested: 986 tests -- FAIL: MultiSource/Applications/Burg/burg.execution_time (494 of 986) FAIL: MultiSource/Applications/ClamAV/clamscan.execution_time (495 of 986) FAIL:

A big compile time regression. Any ideas? Ciao, Duncan. On 22/07/11 19:13, llvm-testresults at cs.uiuc.edu wrote: > > bwilson__llvm-gcc_PROD__i386 nightly tester results > > URL http://llvm.org/perf/db_default/simple/nts/253/ > Nickname bwilson__llvm-gcc_PROD__i386:4 > Name curlew.apple.com > > Run ID Order Start Time End Time > Current 253 0 2011-07-22 16:22:04

Hello; I was able to build and install llvm(3.0) under Ubuntu 11.10 (using the ./configure script found under llvm source, and then make and make install). While configuring, I gave --prefix as a directory where I would like llvm to be installed. I did not give --with-llvmgccdir and the --enable-optimized argument to configure. Because 3.0 doesn't come with llvmgcc source/binaries and I

Hi, I figured out how to resolve the failures. I noticed that Mountain Lion includes Bison 2.3 while Ubuntu 12.04 includes Bison 2.5. I installed Bison 2.3 from source in Ubuntu and the failures went away. I'm a little concerned that the bison version fixed all the failures I was seeing. To my knowledge the only failing test that depended on bison was Burg. It almost looks like one failure

Nothing that I'm aware of has changed with EH. Is it possible to bisect the problem? -bw On Jun 20, 2012, at 12:38 AM, Duncan Sands <baldrick at free.fr> wrote: > Did something change with exception handling recently? A bunch of lit bots are > showing slower compile times for many tests. > > Ciao, Duncan. > > On 20/06/12 07:53, llvm-testresults at cs.uiuc.edu

Did something change with exception handling recently? A bunch of lit bots are showing slower compile times for many tests. Ciao, Duncan. On 20/06/12 07:53, llvm-testresults at cs.uiuc.edu wrote: > > lab-mini-03__O0-g__clang_DEV__x86_64 test results > <http://llvm.org/perf/db_default/v4/nts/1283?compare_to=1278&baseline=999> > > Run Order Start Time Duration >