[M3devel] narrow still failing..

[mika at async.caltech.edu]

The only thing bddtest uses from caltech_parser is Debug.Out.  You can just take out those calls or replace them with IO.Put.

But again bddtest is not the program that fails... it's the "refany" program (now in a sibling directory to bddtest)

   Mika

"Rodney M. Bates" writes:
>
>
>On 01/21/2014 11:11 AM, mika at async.caltech.edu wrote:
>> Did you try using my bdd.tgz ?
>>
>> I am getting this error on:
>>
>> ancient PM3 on FreeBSD4
>>
>> head CM3 on AMD64_LINUX
>
>Hmm.  I can't get any errors compiling bdd and bddtest on my AMD64_LINUX system with
>a freshly updated head.  Hacking around, I tried to use the binaries in bdd.tgz,
>but my .M3SHIP wants a libbdd.so.5, not there.  Some of the *.[im]o files are
>slightly different in size when I recompiled, but I think there is an explanation
>for that.
>
>I can't build bddtest with the release compiler, because it needs caltech_parser,
>and that won't build in the release.  This combination of [non]failures seems
>pretty strange.  I am also wondering about a problem with type checks in the
>runtime.
>
>
>>
>> few months old CM3 on ARM_LINUX (Raspberry Pi)
>>
>> I doubt you will get it on LINUXLIBC6 if you don't get it on the others.
>>
>> I already tried rearranging the files (the implementation and interfaces
>> are split in a funny way across BDD.i3, BDDImpl.i3, BDD.m3, BDDImpl.m3
>> right now).  With no effect.  I don't know what it is about my code that's
>> tripping up the compiler.
>>
>> It's also a "decent" BDD package so someone (me I guess, but anyone
>> else who's interested is welcome to) might want to add it to CM3... :-)
>> Kind of a pain if you can't print out the debugging info though!
>> (Actually the workarounds are OK.)
>>
>>      Mika
>>
>> "Rodney M. Bates" writes:
>>>
>>>
>>> On 01/20/2014 10:18 PM, mika at async.caltech.edu wrote:
>>>> Were you able to get it to fail on any of your computers?
>>>
>>> No, the only times I got narrow failures were due to errors
>>> in my trial cases.
>>>
>>> I have only tried AMD64_LINUX, but should be able to get this onto a
>>> LINUXLIBC6 system.
>>>
>>>>
>>>> Your Z fails for me---CM3 and PM3 both.
>>>>
>>>> (579)truffles:~/bsd/refany/src>../AMD64_LINUX/refany
>>>>
>>>>
>>>> ***
>>>> *** runtime error:
>>>> ***    An explicit or implicit NARROW() operation failed.
>>>> ***    file "../src/Main.m3", line 30
>>>> ***
>>>
>>> Well that torpedos both my theories.
>>>
>>> But it is hard to imagine that bad code generated for an implicit narrow
>>> on an assignment could ever have gone unnoticed so long.  I thought it
>>> might be more believable if it only happened when narrowing an actual
>>> parameter before passing it.
>>>
>>>>
>>>> Abort
>>>> (580)truffles:~/bsd/refany/src>cat Mai
>>>> Main.m3~  Main.m3
>>>> (580)truffles:~/bsd/refany/src>cat -n Main.m3
>>>>        1  MODULE Main;
>>>>        2  IMPORT BDD, IO;
>>>>        3
>>>>        4  PROCEDURE P() : REFANY =
>>>>        5    BEGIN
>>>>        6      VAR x : REFANY;
>>>>        7      BEGIN
>>>>        8        x := BDD.New("a");
>>>>        9        Z(x);
>>>>       10        RETURN x
>>>>       11      END
>>>>       12    END P;
>>>>       13
>>>>       14  PROCEDURE Q() =
>>>>       15    BEGIN
>>>>       16      IO.Put(P() & "\n")
>>>>       17    END Q;
>>>>       18
>>>>       19  (*
>>>>       20  PROCEDURE Z(VAR x : REFANY) =
>>>>       21    BEGIN
>>>>       22      TYPECASE x OF
>>>>       23        BDD.T(b) => x := BDD.Format(b)
>>>>       24      END;
>>>>       25    END Z;
>>>>       26  *)
>>>>       27  PROCEDURE Z(VAR x : REFANY) =
>>>>       28     VAR b: BDD.T;
>>>>       29     BEGIN
>>>>       30       b := x;
>>>>       31       x := BDD.Format(b)
>>>>       32     END Z;
>>>>       33
>>>>       34
>>>>       35
>>>>       36  BEGIN
>>>>       37    Q()
>>>>       38  END Main.
>>>> (581)truffles:~/bsd/refany/src>
>>>> "Rodney M. Bates" writes:
>>>>> What does this do?
>>>>>
>>>>> PROCEDURE Z(VAR x : REFANY) =
>>>>>     VAR b: BDD.T;
>>>>>     BEGIN
>>>>>       b := x;
>>>>>       x := BDD.Format(b)
>>>>>     END Z;
>>>>>
>>>>> The common property of the failing cases seems to be the necessity
>>>>> of a runtime narrow check when passing x to BDD.Format.
>>>>>
>>>>> So far, I haven't been able to reproduce the failure on AMD64_LINUX,
>>>>> with even more irrelevant (one would think) stuff pared out.  I moved
>>>>> T, Root, and Format into main, removed all but one fields of T and Root,
>>>>> replaced BDD.New by NEW(Root) and removed Symtab and most of the body
>>>> >from Format.
>>>>>
>>>>> Looking at your code, I agree it should work.
>>>>>
>>>>>
>>>>> On 01/19/2014 04:01 PM, mika at async.caltech.edu wrote:
>>>>>> As in the ISTYPE/TYPECASE example, the following works:
>>>>>>
>>>>>>
>>>>>> PROCEDURE Z(VAR x : REFANY) =
>>>>>>      BEGIN
>>>>>>        TYPECASE x OF
>>>>>>          BDD.T(b) => x := BDD.Format(b)
>>>>>>        END;
>>>>>>      END Z;
>>>>>>
>>>>>> (244)rover:~/refany/src>../FreeBSD4/refany
>>>>>> a
>>>>>>
>>>>>>
>>>>>> This does NOT work:
>>>>>>
>>>>>> PROCEDURE Z(VAR x : REFANY) =
>>>>>>      BEGIN
>>>>>>        TYPECASE x OF
>>>>>>          BDD.T(b) => x := BDD.Format(x)
>>>>>>        END;
>>>>>>      END Z;
>>>>>>
>>>>>>
>>>>>> (242)rover:~/refany/src>../FreeBSD4/refany
>>>>>>
>>>>>>
>>>>>> ***
>>>>>> *** runtime error:
>>>>>> ***    NARROW failed
>>>>>> ***    file "/big/home/mika/refany/src/Main.m3", line 22
>>>>>> ***
>>>>>>
>>>>>>      use option @M3stackdump to get a stack trace
>>>>>> Abort
>>>>>>
>>>>>>
>>>>>> Same result PM3 / CM3.
>>>>>>
>>>>>>         Mika
>>>>>>
>>>>
>>