Re: [Axiom-developer] 2.7 build

[Camm Maguire]

Greetings!

Waldek Hebisch <address@hidden> writes:

> )set break break
> )lisp (si::use-fast-links nil)
> )read "boo1.input"
> 
> and the segfault went away -- this stage finished without problems.
>  

OK, am trying to reproduce...

> In case of segfault I doubt that a small example is possible. 
> 

OK

> > 
> > For example, in the report below ...
> > 
> > > The second problem is that the function |ICformat| apparently is
> > > miscompiled, Lisp code differs only trivially from code in 2.6.8
> > > build.  In particular at the beggining we have:
> > > 
> > > (DEFUN |ICformat| (|u|)
> > >   (PROG (|v| |l'| |l1| |l|)
> > >     (RETURN
> > >       (SEQ (COND
> > >              ((ATOM |u|) |u|)
> > >              ((AND (PAIRP |u|) (EQ (QCAR |u|) '|has|))
> > >               (|compHasFormat| |u|))
> > >              ((OR (AND (PAIRP |u|) (EQ (QCAR |u|) 'AND)
> > >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T))
> > >                   (AND (PAIRP |u|) (EQ (QCAR |u|) '|and|)
> > >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T)))
> > >               (SPADLET |l|
> > >                        (REMDUP (PROG (#1=#:G7955)
> > 
> > I take it this source is generated by some other function in axiom
> > which is malfunctioning, (akin to the writing of #<compiled function
> > ...> in the generated lisp sources I reported earlier).  What is this
> > function?  How do I run it to produce the above output?  I take it the
> > difference lies in the gensym above -- this appears clearly wrong, and
> > indicates an error either in GCL's compilation of the function that
> > generates this source, or a mistake in one of the patches applied in
> > your tree.  Stephen, can you reproduce this?
> > 
> 
> Let me repeat:  I belive that the Lisp code above is correct.  This
> code is an output of depsys, which translates Boot to Common Lisp.
> The translator extenivly uses gensym-ed symbols, and AFAICS gensym-ed
> work fine.  In fact, what I am saying is: modulo names of gensym-ed
> symbols (which are irrelevant to the meaning) the Lisp code for this
> function produced during 2.7.0 build is identical to Lisp code from
> build using 2.6.8.

My apologies -- I misunderstood you to be saying that the trivial
difference was the cause of the failure.  And the gensym is OK given
the prog.

> 
> This function is contained in the file 'functor.boot.pamphlet' and
> is a part of the Spad compiler.  'functor.boot.pamphlet' is translated
> to Lisp giving 'functor.clip'.  'functor.clip' is compiled to
> 'functor.o'.  'functor.o' is used during Spad compilation.
> 'functor.o' produced by gcl-2.7.0 works incorrectly.
> 

Thank you -- am trying to see if the latest fix for Stephen fixes this
too. 

> > > 
> > > 
> > > however, the call:
> > > 
> > > (|ICformat| '(|and| |foo| |bar| |foo|))
> > > 
> > > in 2.7.0 falls to the end and signals error, while in 2.6.8 compiled
> > > Axiom it works OK.  It looks that Steve had similar problem (but later
> > > wrote that it works OK).
> > > 
> > 
> > I don't see how this is related to Stephen's earlier report regarding
> > logical expression evaluation -- am I missing something?  It appears
> > we have a printing problem in your tree somewhere.
> >
> 
> Well, I belive that the logical expression in the code above is
> evaluated incorrectly.  Basically, the |ICformat| performs a
> series of pattern matches and depending on the outcame chooses
> code to execute.  If no of the patterns matches |ICformat| signals
> error.  The input above should be matched by the expression:
> 
> > >              ((OR (AND (PAIRP |u|) (EQ (QCAR |u|) 'AND)
> > >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T))
> > >                   (AND (PAIRP |u|) (EQ (QCAR |u|) '|and|)
> > >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T)))
> 

Looks very similar to his report now -- again my apologies.

> but apparently, the expression above compiled by 2.7.0 does not
> match (the code takes error branch).  I have modified by hand the
> Lisp file changing the expression above to:
> 
>              ((OR (AND (PAIRP |u|) (OR (EQ (QCAR |u|) 'AND) (EQ (QCAR |u|) 
> '|and|) )
>                        (PROGN (SPADLET |l| (QCDR |u|)) 'T))
>                   (AND (PAIRP |u|) (EQ (QCAR |u|) 'AND)
>                        (PROGN (SPADLET |l| (QCDR |u|)) 'T)))
> 
> 
> Ater such change I was able to succesfully continue the build
> (currently I am running the test suite).
>  

Bet its gone now ...

> So, I belive that the expression above is miscompiled by gcl.  I will
> try to reduce problem to smaller example.
> 

No need.

> > > One extra remark: the extra PROG which I saw previously seem to be
> > > gone -- I am not sure if it is safety 3 or something in gcl changed.
> > > But now I see:
> > > 
> > > (DEFUN |ALIST;dictionary;$;1| ($) (SPADCALL NIL (QREFELT $ 11)))
> > > 
> > > (the same as in other dialects), while earlier 2.7 gave me:
> > > 
> > > (DEFUN |ALIST;dictionary;$;1| ($)
> > >   (PROG () (RETURN (SPADCALL NIL (QREFELT $ 11)))))
> > > 
> > 
> > These are equivalent in lisp, but it still indicates some instability
> > in the axiom code generator.  There is nothing in GCL  that I can see
> > at the moment that would automatically make this conversion.
> >
> 
> Axiom tries to "optimize" generated Lisp code -- removal of PROG is
> almost surely one of such optimizations.  However, Axiom makes various
> unportable assumptions, and probably one of this assumptions is
> (was) broken by the new gcl.
> 
> > Please let me know if my suggestions above are unworkable.
> > 
> > BTW, am assuming we are still working with the source produced by svn
> > update in wh-sandbox as modified by the patches your posted.  If the
> > source tree is different, a complete set of instructions describing
> > how to reproduce this would be most helpful.
> > 
> 
> I am working with the same tree as my first trial at gcl-2.7 build, namely
> revision 636 of wh-sandbox + the patch that I posted.  If you did update
> you probably got revision 646 which is slightly different.
> 

OK, I've reverted exactly to this source for testing.  How are you
testing at safety 3 -- with an initial declaim in saved_ansi_gcl?

Take care,

> 
> -- 
>                               Waldek Hebisch
> address@hidden 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah