Re: [Gcl-devel] New random tester failures

[Camm Maguire]

Greetings, and thanks again as always, Paul!

I have a fix for this, as yet uncommitted.  But I realize as I chase
these down that I need very frequently to rebind arguments in a let*
using gensymmed temporaries, and this has reminded me of a
longstanding performance problem with this I'd like to fix.  In brief,
doing this destroys any type information that may exist for the
rebound variable via declaration or proclamation.

I have plan A and plan B, and would like to solicit your opinion:

A) When the compiler expands macros, or funcalls compiler macro
functions, detect whether new bindings are introduced, and if so,
recursively macroexpand the form, determine whether the binding is
changed in the body of the new let, and if not, add a declaration read
from a stack when appropriate at the head of the let.  Advantage --
centralized -- disadvantage -- could be slightly tricky.

B) Push declarations onto the environment passed to macroexpand, and
rewrite each relevant macro (mostly setf expanders and compiler
macros) to insert the declarations where appropriate.

I'm leaning toward A, but am quite open minded.

Remember your aluding to an Allegro proposal by Duane Rettig (?) when
we discussed this before, but never could find this.

Take care,


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

> Camm Maguire wrote:
> 
> > Thanks again, Paul as always!  OK, try it again now please.  Have made
> > use of the side-effect flag in the optimizer to push intermediary
> > values to the C stack.
> 
> Ok, this appears to be working now.
> 
> I've checked in the updated random tester, along with a bug fix in
> the pruner.  I'm seeing one kind of failure now, related to
> side effects in INCF/DECF forms.  Section 5.1.3 requires
> that expressions like
> 
>      (incf x (setf x y))
> 
> perform the setf *before* retrieving the value from x to be
> incremented (so x ends up = to (+ y y).)  gcl is doing this
> differently in the compiler and the interpreter.
> 
> Many other lisps get this wrong in both compile and eval;
> I added tests for this to incf.lsp and decf.lsp the other
> day after gcl showed I had missed testing this possibility.
> 
> Since I can change the failure rate by tweaking various
> parameters in the random form generator, it might be
> interesting to try increasing the failure rate via
> a genetic algorithm, or perhaps just setting those
> parameters randomly before each iteration.
> 
>       Paul
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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