[M3devel] more m3tests failures

[Tony Hosking]

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;

Hmm.  Something is broken with load_static_link.  I will look into it.

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

Not sure...

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