similar to: [LLVMdev] RFC: Dropping DejaGNU

On Oct 18, 2009, at 7:49 PM, Daniel Dunbar wrote: > Hi all, > > As you may or may not have noticed, I have gradually been replacing > the testing infrastructure in LLVM. Most of this work is moving LLVM > and Clang to share a single testing tool, 'lit'. See: > http://llvm.org/cmds/lit.html > for documentation on the tool itself. > > If you haven't already

On Sun, Oct 18, 2009 at 7:49 PM, Daniel Dunbar <daniel at zuster.org> wrote: > Hi all, > > As you may or may not have noticed, I have gradually been replacing > the testing infrastructure in LLVM. Most of this work is moving LLVM > and Clang to share a single testing tool, 'lit'. See: >  http://llvm.org/cmds/lit.html > for documentation on the tool itself. >

On Mon, Oct 19, 2009 at 2:03 PM, Eric Christopher <echristo at apple.com> wrote: > On Oct 18, 2009, at 7:49 PM, Daniel Dunbar wrote: >> If you haven't already tried it, please consider switch to 'make >> check-lit' as an alternative to 'make check'. If it doesn't work for >> you, or you find it doesn't do something DejaGNU did and you like,

On Oct 18, 2009, at 7:49 PM, Daniel Dunbar wrote: > If you haven't already tried it, please consider switch to 'make > check-lit' as an alternative to 'make check'. If it doesn't work for > you, or you find it doesn't do something DejaGNU did and you like, > please let me know. My eventual plan is to move to lit entirely and > drop DejaGNU support, so

On Sun, Oct 18, 2009 at 7:49 PM, Daniel Dunbar <daniel at zuster.org> wrote: > Hi all, > > As you may or may not have noticed, I have gradually been replacing > the testing infrastructure in LLVM. Most of this work is moving LLVM > and Clang to share a single testing tool, 'lit'. See: > http://llvm.org/cmds/lit.html > for documentation on the tool itself. >

On Oct 19, 2009, at 3:58 PM, Eric Christopher wrote: >> >> Should be possible, although I don't know anything about the dejagnu >> feature. However, 'lit' has a reasonably complete shell and Tcl >> parser >> so it knows what commands are being called, so at least in theory it >> should be able to rewrite them. > > Interesting. Even less of

> > Should be possible, although I don't know anything about the dejagnu > feature. However, 'lit' has a reasonably complete shell and Tcl parser > so it knows what commands are being called, so at least in theory it > should be able to rewrite them. Interesting. Even less of that would be just duplicating the functionality. At any rate everything looks quite nice.

> On Sep 1, 2016, at 9:20 PM, Greg Parker <gparker at apple.com> wrote: > >> On Sep 1, 2016, at 9:06 PM, llvm.buildmaster at lab.llvm.org wrote: >> >> The Buildbot has detected a new failure on builder sanitizer-x86_64-linux-fast while building llvm. >> Full details are available at: >>

On Sat, Jul 8, 2017 at 10:07 AM Daniel Dunbar <daniel_dunbar at apple.com> wrote: > > > On Jul 8, 2017, at 7:32 AM, David Blaikie <dblaikie at gmail.com> wrote: > > Ideally/the better integration with Buildbot would be to have these > outputs referenced as "associated files" (it's been a while since I played > with buildbot - I remember finding this

On Thu, Jan 17, 2013 at 10:59 AM, David Blaikie <dblaikie at gmail.com> wrote: > On Thu, Jan 17, 2013 at 10:51 AM, Daniel Dunbar <daniel at zuster.org> wrote: > > Note that as far as places to put temporary files, the right place to put > > them is alongside the other test outputs in the test output "sandbox" > > directory. > > > > Somewhat

Ideally/the better integration with Buildbot would be to have these outputs referenced as "associated files" (it's been a while since I played with buildbot - I remember finding this and considering how it could be done, but not getting all the way through) so they'd come back as actual files on the build master, linked from the results page that you could click on to

Hi, I am observing a deadlock with llvm-lit on windows 7. When I attached a debugger, the communicate() call is blocked. In file utils/lit/lit/TestRunner.py > # FIXME: There is probably still deadlock potential here. Yawn. > procData = [None] * len(procs) > procData[-1] = procs[-1].communicate() I am invoking python directly on windows to run the unit tests.

Since it came up, what is blocking us from putting these tests in the llvm-gcc test suite instead of in the LLVM test suite? - Daniel On Tue, Jul 14, 2009 at 4:01 AM, Jakob Stoklund Olesen<stoklund at 2pi.dk> wrote: > > On 14/07/2009, at 12.35, Harel Cain wrote: >> When using "make check" with the DejaGNU test collection, I encounter >> two unexpected failures

That depends on what you call a false positive. The public buildbot regularly fails because of mailing Frontend tests, and I have had continues failures of some DejaGNU tests for a long time on some builders. Its not a false positive per se, but one starts to ignore the failures because they aren't unexpected. - Daniel On Wed, Jul 15, 2009 at 4:10 PM, Bill Wendling<isanbard at

> > 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

On Thu, Jan 17, 2013 at 11:19 AM, Daniel Dunbar <daniel at zuster.org> wrote: > On Thu, Jan 17, 2013 at 10:59 AM, David Blaikie <dblaikie at gmail.com> wrote: >> >> On Thu, Jan 17, 2013 at 10:51 AM, Daniel Dunbar <daniel at zuster.org> wrote: >> > Note that as far as places to put temporary files, the right place to >> > put >> > them is

> On Jul 7, 2017, at 2:19 PM, Reid Kleckner <rnk at google.com> wrote: > > On Fri, Jul 7, 2017 at 1:20 PM, George Karpenkov via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Thus, I propose modifying FileCheck default behavior to dump all swallowed output on stderr when the test has failed. > Would there be any objections to

Note that as far as places to put temporary files, the right place to put them is alongside the other test outputs in the test output "sandbox" directory. Somewhat orthogonal, but we should also fix up lit to purge those sandboxes before it starts a new test run. - Daniel On Wed, Jan 16, 2013 at 3:31 PM, Dmitri Gribenko <gribozavr at gmail.com>wrote: > On Thu, Jan 17, 2013

On Thu, Jan 17, 2013 at 10:51 AM, Daniel Dunbar <daniel at zuster.org> wrote: > Note that as far as places to put temporary files, the right place to put > them is alongside the other test outputs in the test output "sandbox" > directory. > > Somewhat orthogonal, but we should also fix up lit to purge those sandboxes > before it starts a new test run. SGTM -

On Jul 15, 2009, at 4:48 PMPDT, Daniel Dunbar wrote: > That depends on what you call a false positive. The public buildbot > regularly fails because of mailing Frontend tests, and I have had > continues failures of some DejaGNU tests for a long time on some > builders. Its not a false positive per se, but one starts to ignore > the failures because they aren't unexpected. Yes.