gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] ansi-tests on a thinkpad & cetera


From: Camm Maguire
Subject: Re: [Gcl-devel] ansi-tests on a thinkpad & cetera
Date: 28 Jan 2004 21:56:26 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

"Paul F. Dietz" <address@hidden> writes:

> Camm Maguire wrote:
> 
> > Greetings!  Paul, can you isolate the crash on cvs head caused by your
> > latest tests?
> 
> I believe the memory corruption may be introduced by a test in 
> ansi-tests/ccase.lsp.
> This expression
> 
>    (funcall (macro-function 'ccase))
> 
> should throw a program-error (missing required arguments), but doesn't.
> 

Yes this is because at present, GCL only checks the number of
arguments of compiled functions when *safety* >=1.  I've just fixed
this (not yet committed) by (proclaim '(optimize (safety 1))) in
clcs_macros.lisp.  Unfortunately, I do not yet undersand the precise
definitions of the safety levels.  I'd like GCL supplied code to be
correct under all user invocations, but fully optimized in the sense
that calls by this code to other GCL supplied functions are not
checked.  I'd greatly appreciate elucidation of the meaning of the
safety levels, as well as ideas on a conceptual decomposition of the
process of compilation into items which can be fully optimized once
the code and its subcalls has been determined to be correct and items
which might possibly depend on unreviewed user input.  Apparently, the
assumption was made that macro expansion functions would only be
called by GCL itself during macro expansion.

> Commenting out the three ccase error tests causes the test suite to get
> much farther (it eventually stops with a printer error in
> upgraded-array-element-type.nil.1.)
> 

Here is the offending statement:

(format t "Actual value~P: #<error during printing>~%")

I take it this is a GCL error.  I haven't yet read the docs on this
format escape, but apparently it should print an 's' when there are
multiple arguments.  I'll look into fixing this, but you surely don't
need the -P in this case, no?

With the above fix and removing the ~P, there is yet a further issue
(likely due to unchecked compiled macro arguments) somewhere further
down the suite, which I'd appreciate your assistance in isolating if
you have time.  I'm just trying to get a quick completion of the test
suite to push out another gclcvs Debian package.  We obviously will
have more serious work to do in the near future.


Take care,

>       Paul
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]