RE: [Gcl-devel] STABLE, WINDOWS: read_fasd1() and alloc_relblock()

[Billinghurst, David (CALCRTS)]

I started to look into some of this, but got sidetracked
when one of my molars decided to split.  Ouch.
> Using the Maxima 20040219 source package (both with and without
> ignore-errors) and stable CVS GCL (which contains my fixes of last night):
> 
> 1. GCL/gcc 3.3.1/binutils 2.14.90 builds Maxima and passes tests both with
> and without ignore-errors - I haven't been able to replicate the
> "ignore-errors" path mangling bug so that looks good.

With this combination maxima builds and passes tests.  Haven't tried 
"ignore-errors"

> 2. GCL/gcc 3.3.3/binutils 2.15.90 still causes the Maxima crash.  It now
> crashes consistently (which is also good news) while loading
> "binary-gcl/specfn.o" so if we still have the fortitude and time we can
> probably track it down.
>
> The problem occurs in the Maxima source file "src/clmacs.lisp", function
> "aset-by-cursor" called in "fillarray":

I played mix and match.  I have:
 - gcc-3.3.1 and gcc-3.3.3
 - CVS gcl from last Friday built with both gcc's

By a process of elimination, I found that the maxima crash above
occurs when the maxima routine clmacs.lisp is compiled with gcc-3.3.3
It does not depend on the gcc used to compile gcl

That isn't the end of the problem, as the compiled maxima crashed in the 
testsuite.  

I can use a gcc-3.3.3 compiled gcl to build a working maxima if I use 
gcc-3.3.1 for the maxima build.