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

[Camm Maguire]

Greetings!

"Mike Thomas" <address@hidden> writes:

> Hi Camm.
> 
> Camm wrote:
> 
> | Fantastic!!  Was it the -fno-inline-functions or the getc redefine?
> | I'm guessing the former.  In fact, with the former, why do you need
> | the latter?
> 
> My thoughts exactly, but neither option by itself is sufficient to get a
> complete "make test-unixport" - the former is needed to get through the
> remainder of the test run once the latter fixes the "rt.o" load hang.
> 
> As reported yesterday, the same set of flags was sufficient to compile
> Maxima with gcc 3.3.1/GCL, overcoming the so-called "ignore-errors" bug.
> That is all good.
> 
> Unfortunately the random tester died after about 400 iterations.
> 

With what symptoms?

> Worse, I spent last night trying various combinations of optimisation flags
> and am entirely unable to come up with a set which can do both of:
> 
>   1. Survive more than 700 cycles of the random tester and
>   2. Overcome the "ignore-errors" bug in Maxima.
> 
> I can only achieve one or the other.  Many combinations cause a recurrence
> of the Maxima path mangling bug as well.
> 

Including no optimization at all?

> To satisfy my curiosity I tried the older MinGW32 gcc 3.2.1 and 3.2.3 with
> whatever binutils came therewith and got in both cases a continuous cyclical
> rebuild of PCL caused by a memory error comnpiling "pcl/gazonk1.lsp".
> 
> I have yet to try a gcc 2.95 as I haven't got one lying around.
> 

I think older versions of gcc might be a waste of time.

I suggest we work with no optimizations for right now, which is what
you should get when configuring with --enable-debug.  Leave your
#ifdef of getc in, as this is a known bug in the runtime.
-fno-inline-functions should be implied by the lack of O flags.  In
this setting, what are the results of the ansi-suite, the random
tester, and the maxima build with both gcc 3.3.1 and gcc 3.3.3?

We cannot be sure that we are closing bugs (i.e. name-mangling) by
just seeing them disappear with certain gcc flags.  Indeed, if they
reappear with any set of flags, it is likely that their absence with
certain flags is only a fortunate coincidence of memory, stack and
register usage.  This is unless of course there is a known issue with
either the runtime or compiler which is a priori known to be avoided
by the flag selection in question.  

So I think we should focus on no optimization, and see what bugs we
can reproduce here -- these should provide a real and reproducible
baseline which should expose any problems in gcl proper.  If we can
get stability here, we might just want to ship this as the default
with 2.6.2.

Take care,

> 
> | > 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
> |
> |                        ^^^^^^^^^^^^^^^^^^^^^^^^
> |
> | Indeed.  Any idea of why the inline function optimization produced
> | *irregular* crashes?
> 
> None other than the guess that memory was being corrupted randomly?
> 
> 
> |
> | > "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":
> | >
> |
> | OK, my suggestion here would be to configure gcl with debugging, and
> | build maxima with --enable-gcl --enable-gcl-alt-link.  This will give
> | you an image fully addressable within gdb.  If the build doesn't
> | complete, as is likely, just link in the clmacs.o file with
> |
> | (compiler::link (list "clmacs.o") "new_gcl")
> |
> | and restart the problem command with new_gcl under gdb, adjusting the
> | command so as not to reload clmacs.o.
> |
> | You might also want to just try the vanilla maxima build under gdb and
> | get a backtrace to the location within aset-by-cursor that causes the
> | crash.
> 
> Will try this later.
> 
> | Separately, it appears from Vadim's email that I've been mistaken in
> | thinking gcc 3.3.3 was the latest official gcc on mingw, in which case
> | chasing down this problem now would be critical.  Is gcc 3.3.3 on
> | mingw only a 'candidate'?  If so, the bug is still important, but not
> | so crtitical as to further delay the release IMHO if the information
> | gleaned from the above steps reveals a time consuming job ahead of us.
> 
> In principal I agree except that the problems with 3.3.1 appear to be just
> as great as with 3.3.3 if we expect to make a release which passes all the
> tests - there is (at least one) something fundamentally wrong and we haven't
> found it yet.
> 
> Incidentally, I note that there are many functions in "h/cmpinclude.h" which
> include a return value type but not the types of their arguments.  Thinking
> that the path coercion functions might be at the heart of the Maxima path
> problem I changed the relevant declarations but to no avail:
> 
> object coerce_to_pathname(object);
> /* object default_device(); */
> object merge_pathnames(object,object,object);
> object namestring(object);
> object coerce_to_namestring(object);
> 
> However there are many functions still to go and I am curious whether you
> think that this might be confusing the compoiler or linker?
> 
> | Thanks again to both of you for your *fantastic* work here!
> 
> Thanks.
> 
> Cheers
> 
> Mike Thomas.
> 
> 
> 
> 
> _______________________________________________
> 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