<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Here is a QUICK rundown.<BR>
<BR>p004 I /assume/ this is the same on all platforms<BR> but didn't check<BR>
<BR>p051 extra print out when building specific to NT386,<BR> fixed, but at great loss of diagnosability IF<BR> there are errors in compiling C code<BR>
<BR>Specifically, given<BR> cl -nologo -c foo.c bar.c<BR>the compiler prints<BR>foo.c<BR>bar.c<BR>
<BR>to the same channel as errors (stderr or stdout)<BR>So when running the tests, NT386.common has a hack to throw<BR>out all C compiler output.<BR>
<BR>p116b floating point issue, probably same on all platforms<BR>p126 ditto<BR>p172 ditto<BR>p186 ditto<BR>
<BR>p204 compiler bug<BR> I think this also fails on other platforms but obviously<BR> differently; needs investigation<BR>
<BR>p205 was failing but I put in a fix and then Tony put in a better fix<BR>
<BR>p206 I think this fails the same on all platforms, but I <BR> I think it behaves correctly and just update the<BR> std{out,err}.{pgm,build} files; since it is a compilation<BR> failure, it should be an 'e' instead of 'p', not<BR> a big deal I think<BR>
<BR>p207 probably fall out from longint not being 64 bits<BR> probably should disable just for this platform <BR>
<BR>r001 This test works in general but is a problem for the<BR> Tinderbox in general. LINUXLIBC6 and NT386 should be<BR> passing, but I think probably it should be turned off.<BR> In particular, the way programs exit when they<BR> fail an assertion and/or have an unhandled exception<BR> varies by platform, in terms of what they actually print.<BR>
<BR>r002 needs investigation; I think it's an infinite recursion<BR> or just uses a lot of stack, and I THINK I saw it fail<BR> on other platforms <BR>
<BR>r003 I hadn't looked at this AT ALL but probably the same as r001,<BR> except more interesting?<BR> There is a test that catches an assertion failure, maybe<BR> do that here?<BR> As well, there is the annoying idea of making per-platform <BR> std* files. Hard to maintain.<BR>
<BR>
r004 ditto -- since there are four of these, and potentially more,<BR> maybe worth coming up with something<BR>
<BR>Something I considered, but rejected, back when I thought r001<BR>was the only one, is a runtime switch <A href="mailto:M3@consistentAbort">M3@consistentAbort</A> or<BR>somesuch that will just cleanly exit(0) or exit(1) in these cases,<BR>and not print a callstack. I don't want to foul up the<BR>system TOO much for the sake of testing, but testability<BR>is an expected design goal...<BR>
<BR>Again, this is an issue across platforms.<BR> LINUXLIBC6 seems to print something slightly differently<BR> every time you run these. Test.common has a gross workaround.<BR>
The checked in std* files are from FreeBSD.<BR>
<BR>e020 unknown so far<BR>
<BR>e026 was a problem on all platforms and should be ok now;<BR> was a compiler bug, I fixed<BR>
<BR>e029 unknown so far<BR>
<BR>I think p209 and p210 are the most important currently.<BR>And then maybe e020, e029.<BR>
<BR>I expect to be "out" all of Sunday.<BR>
<BR>The Tinderbox SHOULD be OK now.<BR>Sorry...<BR>
<BR>
<BR> - Jay<BR><BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Sun, 4 May 2008 15:30:40 +0200<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: [M3devel] Tinderbox tests on NT386<BR>> <BR>> In case anybody wonders about<BR>> <BR>> http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html<BR>> <BR>> and following reports, I'm currently trying to run the m3tests on<BR>> NT386 in an older version to get a usable reference for the current<BR>> problems. There have been so many changes that I'm unable to keep<BR>> up with them, and some things seem to be broken.<BR>> <BR>> Except for the problems in m3tests, the rest of the tinderbox<BR>> regression test framework seems to be working now for regular<BR>> regression tests on Windows XP with Cygwin. Some initialization<BR>> scripts are needed for running them, but that was to be expected.<BR>> <BR>> The m3tests reports for the last two days for all target platforms<BR>> in the tinderbox are not correct (at least, if they show no errors);<BR>> there have been some structural changes and more things need to be<BR>> adapted. Jay Krell is working on it.<BR>> <BR>> Olaf<BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR></body>
</html>