similar to: [LLVMdev] configure errors

llvm-test, I think. Reid Spencer wrote: >On Tue, 2004-12-28 at 22:47, Jeff Cohen wrote: > > >>I see two minor configure errors on FreeBSD. The first is: >> >>checking for mmap of files... yes >>checking if /dev/zero is needed for mmap... test: FreeBSD: unexpected >>operator >>no >> >> > >That was a bug and I just fixed it.

On Tue, 2004-12-28 at 22:47, Jeff Cohen wrote: > I see two minor configure errors on FreeBSD. The first is: > > checking for mmap of files... yes > checking if /dev/zero is needed for mmap... test: FreeBSD: unexpected > operator > no That was a bug and I just fixed it. Thanks for pointing it out. > The second: > > checking for python... true python > test: : bad

Jeff, I don't have the correct autoconf tools for regenerating llvm-test's configure script which it needs. So, I'll check in the changes to configure.ac but leave the rest to someone else (Misha?) to fix. The llvm-test autoconf stuff is woefully out of date, unfortunately. Reid. On Tue, 2004-12-28 at 23:06, Jeff Cohen wrote: > llvm-test, I think. > > Reid Spencer wrote:

Chris, What's the current status of the test suite. After putting everything in the llvm namespace and getting everything to link, I am getting only about 75% of the tests passing. Is this to be expected or have I broken something? Reid. -------------- next part -------------- An HTML attachment was scrubbed... URL:

I'm re-thinking my penchant for automake. automake is great for many standard applications that just need to get portable makefiles up and running quickly. However, it turns out that LLVM is "different enough" from a standard application that automake might not be the best choice. Here's some of the problems I've run into: 1. There's no way to tell automake to build

On Wed, Dec 29, 2004 at 08:37:46AM +0200, Alex Vinokur wrote: > But it seems that there are no asterisks at > * http://llvm.cs.uiuc.edu/testresults/ > * http://llvm.x10sys.com/testresults/Cygwin/ That's because there was a build error (see the big red notice). Check out http://llvm.x10sys.com/testresults/Cygwin/2004-12-27.html > By the way, is it possible to send a relevant

On Sunday 28 November 2004 00:24, Tanya Lattner wrote: Just some comments from a QMTest user... Note however, that even with them, dejagnu looks better. > Cons of QMTest: > 1) You have to use the gui to add directories. I think you're wrong. Manually creating a directory would work, as QMTest does not place anything special in directories. > 2) You have to use the gui to XFAIL

> > Cons of QMTest: > > 1) You have to use the gui to add directories. > > I think you're wrong. Manually creating a directory would work, as QMTest does > not place anything special in directories. I may have worded this poorly, but I think you have to use the gui to add new directories or tests, or specific tests. Otherwise, it does not know what to do with those

Tanya Lattner wrote: > I've finished adding the -rundejagnu option to the nightly tester script, > which was the last step to fully support Dejagnu. I think now is the > appropriate time to discuss keeping QMTest or switching to Dejagnu. A lot > of work went into using QMTest, so I think we should make this decision > carefully and before the 1.4 release. > > Here are the

Brian Gaeke wrote: > > A typo in test/Makefile was the trigger for this problem: > > http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/ > 020216.html > > John, can you please look into this bug some more and add some error > checking to the llvm-specific qmtest python modules to make this error > less severe? Does the fork bomb occur in the

I've finished adding the -rundejagnu option to the nightly tester script, which was the last step to fully support Dejagnu. I think now is the appropriate time to discuss keeping QMTest or switching to Dejagnu. A lot of work went into using QMTest, so I think we should make this decision carefully and before the 1.4 release. Here are the pros and cons in my eyes, please feel free to add your

A typo in test/Makefile was the trigger for this problem: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/ 020216.html John, can you please look into this bug some more and add some error checking to the llvm-specific qmtest python modules to make this error less severe? Thanks! -Brian On Nov 3, 2004, at 10:35 AM, Brian Gaeke wrote: > > I think there is a very

I attempt install and use qmtest for run LLVM testsuit at FreeBSD, but without success. I have installed qm-2.2 (latest and single version accessable from http://www.codesourcery.com/qmtest/download.html in sources) When I start qmtest for LLVM ("make qmtest" in <llvm-obj-dir>/test directory - right?) error printed: ---8X---------------

I think there is a very similar situation with the PowerPC/Mac OS X nightly tests. Over each of the past few nights, something has been filling up the process table, causing me to be unable to log in. The nightly tester wrote out regression test and feature test logs featuring hundreds of "Resource temporarily unavailable" errors from fork(), so I assume it's the qmtest

On Fri, 20 Aug 2004 08:52:28 -0700 Reid Spencer <reid at x10sys.com> wrote: > Hi Jeff, > > On Fri, 2004-08-20 at 08:07, Jeff Cohen wrote: > > OK. I've built the front end without any heartaches, but I did > > encountered the following glitches: > > > > The documentation of --with-llvmgccdir is a bit ambiguous. I had to > > try several paths

>> > I assume you're talking about the FreeBSD run. I'm not sure what is >> > going >> > on >> >> No. You can see problem with Feature tests at >> http://llvm.cs.uiuc.edu/testresults/X86/ also (see Feature Test Results >> section ) > > I'm not sure that I follow. The qmtest stuff isn't working on Zion > because (I

Here's the patch to Signals.cpp. assuming that stdio.h is acceptable (can't imagine it won't work). On Fri, 24 Sep 2004 09:29:05 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > Uh... this may be a silly question, but why can't you include <stdio.h>? > It'd be much better than <iostream>. > > Anyway, I think I'll try this weekend to come

On Fri, Sep 24, 2004 at 09:38:44AM -0700, Jeff Cohen wrote: > Here's the patch to Signals.cpp. assuming that stdio.h is acceptable > (can't imagine it won't work). We prefer #include <cstdio>, since this is C++ after all. :) -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

Sigh... take it up with Microsoft. On Fri, 24 Sep 2004 12:06:36 -0500 Misha Brukman <brukman at uiuc.edu> wrote: > On Fri, Sep 24, 2004 at 09:38:44AM -0700, Jeff Cohen wrote: > > Here's the patch to Signals.cpp. assuming that stdio.h is acceptable > > (can't imagine it won't work). > > We prefer #include <cstdio>, since this is C++ after all. :) >

On Sat, Aug 21, 2004 at 04:15:49PM -0700, Jeff Cohen wrote: > I don't know if it's under cvs. It's the "getting started" page > (http://llvm.cs.uiuc.edu/docs/GettingStarted.html) in section "Getting > Started Quickly (A Summary)". But careful reading of the remainder of > the page does give the correct path. http://llvm.cs.uiuc.edu/docs/* is a copy of