[M3devel] Tinderbox tests on NT386

Sun May 4 18:06:25 CEST 2008

Olaf, You have p137 failing now, which is/was consistent with me.And still p051 failing for you. I fixed that, but  the fix is half in NT386.common, and half in m3tests. You take that  for each build? The situation there is/was kind of  unfortunate -- all compiler output is quashed, errors and all.
  If we could have per-platform std* files,  this would be one to do that for. You know,  if stdout.pgm.PLATFORM exists, use it, otherwise stdout.pgm.  Problem is whenever the output changes, updating them all.

 - Jay

> Date: Sun, 4 May 2008 16:49:26 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] Tinderbox tests on NT386> > Quoting Jay <jayk123 at hotmail.com>:> > > I'm also seeing lots of failures in p137> >> > --- p137 --- bit insert and extract> > --- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ > > ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 > > -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 > > instead of 819734015+************************ ERROR: 14427647 > > instead of 819734015...> > lotsYou never saw that Olaf?> > p137 was OK on 2008-05-01. Use> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > as a reference; I won't overwrite that anymore now.> Current results of m3tests will be reported to> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-31.html> > soon (sorry for the wrong dates, I'm re-using existing workspaces> here; it would take too long otherwise).> > I'll be out soon, but will have another look later this evening how> things develop.> > Olaf> > > > I should have printed the test names below, it's too hard to read > > with just numbers..> > Anyway, just looking busy I guess, no matter, we'll get around to them..> > (And sorry about the Win32 bitmap stuff, I haven't forgotten...)> >> > Hm..maybe related? Older version of m3tests statically links to > > libm3/m3core but current version dynamically links.> > That'd be cool if it correlates -- if p137 and the bitmap stuff are > > the same problem.> > I'll go try p137 again both ways.> > - Jay> >> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > > m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: > > Re: [M3devel] Tinderbox tests on NT386> >> >> > Here is a QUICK rundown.p004 I /assume/ this is the same on all > > platforms but didn't checkp051 extra print out when building > > specific to NT386, fixed, but at great loss of diagnosability IF > > there are errors in compiling C codeSpecifically, given cl > > -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same > > channel as errors (stderr or stdout)So when running the tests, > > NT386.common has a hack to throwout all C compiler output.p116b > > floating point issue, probably same on all platformsp126 dittop172 > > dittop186 dittop204 compiler bug I think this also fails on other > > platforms but obviously differently; needs investigationp205 was > > failing but I put in a fix and then Tony put in a better fix p206 I > > think this fails the same on all platforms, but I I think it > > behaves correctly and just update the std{out,err}.{pgm,build} > > files; since it is a compilation failure, it should be an 'e' > > instead of 'p', not a big deal I thinkp207 probably fall out > > from longint not being 64 bits probably should disable just for > > this platform r001 This test works in general but is a problem for > > the Tinderbox in general. LINUXLIBC6 and NT386 should be > > passing, but I think probably it should be turned off. In > > particular, the way programs exit when they fail an assertion > > and/or have an unhandled exception varies by platform, in terms > > of what they actually print.r002 needs investigation; I think it's > > an infinite recursion or just uses a lot of stack, and I THINK I > > saw it fail on other platforms r003 I hadn't looked at this AT > > ALL but probably the same as r001, except more interesting? > > There is a test that catches an assertion failure, maybe do that > > here? As well, there is the annoying idea of making > > per-platform std* files. Hard to maintain. r004 ditto -- since > > there are four of these, and potentially more, maybe worth > > coming up with somethingSomething I considered, but rejected, back > > when I thought r001was the only one, is a runtime switch > > M3 at consistentAbort orsomesuch that will just cleanly exit(0) or > > exit(1) in these cases,and not print a callstack. I don't want to > > foul up thesystem TOO much for the sake of testing, but > > testabilityis an expected design goal...Again, this is an issue > > across platforms. LINUXLIBC6 seems to print something slightly > > differently every time you run these. Test.common has a gross > > workaround. The checked in std* files are from FreeBSD.e020 unknown > > so fare026 was a problem on all platforms and should be ok now; > > was a compiler bug, I fixede029 unknown so farI think p209 and p210 > > are the most important currently.And then maybe e020, e029.I expect > > to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry... > > - Jay> >> >> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> > >> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on > >> NT386> > In case anybody wonders about> > > >> http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > > >> and following reports, I'm currently trying to run the m3tests on> > >> NT386 in an older version to get a usable reference for the > >> current> problems. There have been so many changes that I'm unable > >> to keep> up with them, and some things seem to be broken.> > Except > >> for the problems in m3tests, the rest of the tinderbox> regression > >> test framework seems to be working now for regular> regression > >> tests on Windows XP with Cygwin. Some initialization> scripts are > >> needed for running them, but that was to be expected.> > The > >> m3tests reports for the last two days for all target platforms> in > >> the tinderbox are not correct (at least, if they show no errors);> > >> there have been some structural changes and more things need to be> > >> adapted. Jay Krell is working on it.> > Olaf> -- > Olaf Wagner -- > >> elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Gebäude 12, > >> 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 > >> 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | > >> Geschäftsführer: Olaf Wagner | Sitz: Berlin> Handelregister: > >> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194>> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080504/48ff5937/attachment-0002.html>