[M3devel] more m3tests failures
Tony Hosking
hosking at cs.purdue.edu
Mon Jan 7 15:56:12 CET 2008
On Jan 5, 2008, at 3:00 PM, Olaf Wagner wrote:
> I've looked into some more failures of m3tests, which I'd like to
> present to the whole list: (All tests run on FreeBSD 6.3)
>
> p035 is a scoping problem which was Ok with
>
> /usr/local/cm3/bin/cm3cg-5.4.0
>
> but
>
> /usr/local/cm3/bin/cm3cg-d5.5.1
>
> fails, so it must be caused by recent gcc changes. The check that
> fails is
>
> PROCEDURE foo (p: P; same: BOOLEAN) =
> BEGIN
> checkB (bar = p, same); checkB (bar # p, NOT same);
> END foo;
> PROCEDURE bar (<*UNUSED*> t: Text.T) =
> BEGIN
> END bar;
> BEGIN
> msg ("group M"); foo (bar, TRUE);
> msg ("group N"); foo (dummy, FALSE);
> END;
I think the issue is to do with the fact that we use gcc's automatic
nested function support instead of m3cg's load_static_link and
pop_static_link. I believe the fix is to make load_static_link load
nil instead of an actual static chain value.
>
> p040 fails due to differences in floating point precision; the numbers
> on FreeBSD seem to have a higher precision.
>
> +++ ../src/p0/p040/stdout.pgm 2003-03-08 11:14:03.000000000 +0100
> @@ -964,85 +964,85 @@
> ToLongFloat => 0.1 / 3
>
>
> -0.001234567890123456
> +0.0012345678901235
>
> - FromLongFloat [Flo] => 0.001234567890123
> - ToLongFloat => 0.001234567890123 / 17
> - FromLongFloat [AltFlo] => 0.001234567890123
> - ToLongFloat => 0.001234567890123 / 17
> - FromLongFloat [Sci] => 1.234567890123456D-3
> - ToLongFloat => 0.001234567890123456 / 20
> - FromLongFloat [AltSci] => 1.234567890123456D-3
> - ToLongFloat => 0.001234567890123456 / 20
> - FromLongFloat [Mix] => 0.001234567890123
> - ToLongFloat => 0.001234567890123 / 17
> + FromLongFloat [Flo] => 0.001234567890124
> + ToLongFloat => 0.001234567890124 / 17
> + FromLongFloat [AltFlo] => 0.001234567890124
> + ToLongFloat => 0.001234567890124 / 17
> + FromLongFloat [Sci] => 1.234567890123500D-3
> + ToLongFloat => 0.0012345678901235 / 20
> + FromLongFloat [AltSci] => 1.2345678901235D-3
> + ToLongFloat => 0.0012345678901235 / 18
> + FromLongFloat [Mix] => 0.001234567890124
> + ToLongFloat => 0.001234567890124 / 17
>
> I'm not sure here what to do, as well as for p070, which tests
> fingerprints for procedures, and is not implemented in CM3. Do we
> need that? From RTProcedure.m3:
>
> PROCEDURE ToFingerprint (<*UNUSED*> p: Proc): Fingerprint.T =
> BEGIN
> <*ASSERT FALSE, "RTProcedure.ToFingerprint is not supported" *>
> RETURN Fingerprint.Zero; <*NOWARN*>
> END ToFingerprint;
>
> PROCEDURE FromFingerprint (<*UNUSED*> READONLY fp: Fingerprint.T):
> Proc =
> BEGIN
> <*ASSERT FALSE, "RTProcedure.FromFingerprint is not supported" *>
> RETURN NIL; <*NOWARN*>
> END FromFingerprint;
>
> Or should we deactivate that test?
I suspect we should deactivate both of these for now.
>
> p096 fails with
>
> @@ -1,3 +1,2 @@
> "../src/Main.m3", line 27: default is not a procedure constant (m)
> 1 error encountered
> -Fatal Error: package build failed
> --- p0/p096/stderr.build 2008-01-05 18:27:24.000000000 +0100
> +++ ../src/p0/p096/stderr.build 2003-03-08 11:14:05.000000000 +0100
>
> because of this code:
>
> MODULE Main;
>
> CONST K = T.m; L = Q;
> TYPE TProc = PROCEDURE(s: T);
> CONST A = ARRAY OF TProc{Q};
>
> TYPE T = OBJECT METHODS m() := L; END;
> ST1 = T OBJECT OVERRIDES m := K END;
> (*** ILLEGAL *** ST2 = T OBJECT OVERRIDES m := TProc END; ***)
> ST3 = T OBJECT OVERRIDES m := A[0]; END;
>
> PROCEDURE Q(s: T) = BEGIN EVAL s END Q;
>
> VAR t: T; st1: ST1; st3: ST3;
> BEGIN
> EVAL t; EVAL st1; EVAL st3;
> END Main.
>
> I think I can somehow understand the compiler here. Did this ever
> work?
Is "CONST K = T.m" not a procedure constant? In which case m := K
should work!
>
> p116 first fails because FlotMode procedures are not implemented by
> default:
>
> +++ ../src/p1/p116/stderr.pgm 2003-03-08 11:13:53.000000000 +0100
> @@ -1,11 +1,3 @@
> -
> -
> -***
> -*** runtime error:
> -*** <*ASSERT*> failed: FloatMode.SetRounding not implemented
> -*** file "../src/float/IEEE-default/FloatMode.m3", line 14
> -***
> -
> ---------------------------- REAL ---
> 1.0/0.0 # 1.0/(-0.0) test OK
> 1.0/0.0 = 1.0/(- (-0.0)) test OK
>
> I think this should be tested conditionally depending on platform.
Indeed.
> But then more checks fail:
>
> @@ -25,14 +17,14 @@
> Class (MaxFinite*ten) test OK
> Finite (MaxFinite*ten) test OK
> IsNaN (MaxFinite*ten) test OK
> -** Class (zero/zero) test not OK: FALSE should be TRUE
> + Class (zero/zero) test OK
> Finite (zero/zero) test OK
> IsNaN (zero/zero) test OK
> Sign (zero) test OK
> Sign (minusZero) test OK
> - Unordered (zero, NaN) test OK
> +** Unordered (zero, NaN) test not OK: FALSE should be TRUE
> Unordered (zero, zero) test OK
> - Unordered (NaN, NaN) test OK
> +** Unordered (NaN, NaN) test not OK: FALSE should be TRUE
> Differs (zero, NaN) test OK
>
> which refers to the test lines
>
> BCheck("Class (zero/zero)", RealFloat.Class(x) =
> IEEEClass.QuietNaN, TRUE);
> BCheck("Unordered (zero, NaN)", RealFloat.Unordered(zero, NaN),
> TRUE);
> BCheck("Unordered (NaN, NaN)", RealFloat.Unordered(NaN, NaN),
> TRUE);
>
> Especially the last one suprises me, but I'm no specialist in
> arithmetics.
> Is this to be expected? Should we tolerate or can we fix it?
>
> So far for now, I need to prepare dinner now,
>
> 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
>
More information about the M3devel
mailing list