[Top][All Lists]

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

[Gcl-devel] Re: problem with gcl-2.7.0-t2

From: Camm Maguire
Subject: [Gcl-devel] Re: problem with gcl-2.7.0-t2
Date: 07 Jul 2005 09:41:05 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


Just a quick note that I can confirm this problem -- introduced when
we allowed passing of unboxed bignum GMP objects as function
parameters.  While this could allow for future optimizations involving
direct gmp calls from compiled code, I think the gains likely minor
unless others express such a need.  So I plan on disabling GEN args as
function parameters.  But in case we ever reallow them, I plan on
inserting a little C code to copy any unboxed bignums found in the
function parameter list to the local stack.  The GCL model assumes
that all function parameters are local copies (pass by value) on the
stack so it can write tail recursion without consuming any extra
memory by simply reassigning the variables.  I might have a fix by
day's end for both.  In the meantime, you can increase the safety
level of the compile for these functions (from the default of 0) until
this problem goes away.  One can locally declare the optimization
level in the function body.

Take care,

<address@hidden> writes:

> "Eric W. Smith" <address@hidden> wrote on 07/06/2005 02:21:03 PM:
> > Camm,
> >
> > We at Rockwell are using gcl-2.7.0-t2 and we found a bug which we boiled 
> > down
> > to the following somewhat odd example.  Could you take a look?
> >
> > Thanks,
> > -Eric Smith
> >
> > (defun foo (n y)
> >   (if (<= n 18)
> >       y
> >     (foo 17 y)))
> >
> > (proclaim '(function foo (unsigned-byte t) t))
> >
> > (compile 'foo)
> >
> > ;We expect this to return 2147483648 (since x shouldn't get changed) but it
> > returns 17 !  All seems to work correctly here if we skip the compile step.
> >
> > (let* ((x 2147483648)
> >        (y (foo x 0))
> >        )
> >   x)
> >
> Additional information: this is the result on GCL 2.7.0 t2 with 
> lsp/gcl_predlib.lsp replaced with the version from CVS
> HEAD as of Tuesday, as you had instructed us.  When I rebuild GCL 2.7.0 t2 
> with the "original" gcl_predlib.lsp, this
> problem goes away (but we regain the other "old" proclaim problem that I 
> noted at the end of last week).
> Thanks in Advance,
> David Hardin

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]