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

[Mike Thomas]

Camm.

I'm leaving so this is the last I can reply to for now (possibly up to 3
days):
| > Unfortunately the random tester died after about 400 iterations.
| >
|
| With what symptoms?

None - it just returns to the shell prompt.


|
| > 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?

Yes.

|
| > 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.

Me too.

|
| 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?

Tried some of this earlier this morning and yesterday with 3.3.1 - RT is OK,
Maxima has path construction bug (before the new pathname.d patch).


|
| 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.


Agreed.

Got to run.


|
| 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
|
|
| _______________________________________________
| Gcl-devel mailing list
| address@hidden
| http://mail.gnu.org/mailman/listinfo/gcl-devel
|