RE: [Gcl-devel] 2.6.2

[Mike Thomas]

Hi Camm.

I still didn't manage to set aside time for a serious gdb session but a few
background tweaks, reconfigures and builds with tests made it into my day's
efforts.

The set/longjump clue may have paid off with respect to the "universe.lsp"
bug.


Further info on Windows setjmp/longjmp from MSDN:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/
_crt_longjmp.asp

"A call to setjmp causes the current stack environment to be saved in env. A
subsequent call to longjmp restores the saved environment and returns
control to the point immediately following the corresponding setjmp call.
Execution resumes as if value had just been returned by the setjmp call. The
values of all variables (except register variables) that are accessible to
the routine receiving control contain the values they had when longjmp was
called. The values of register variables are unpredictable. The value
returned by setjmp must be nonzero. If value is passed as 0, the value 1 is
substituted in the actual return.

Call longjmp before the function that called setjmp returns; otherwise the
results are unpredictable."


The fact that a longjmp() return value of zero is changed to one seems to
have been accounted for in "format.c", assuming the entry value of the bool
variable "colon" is <> -1.  Perhaps a check there would be warranted for
debugging.

To check the possible effects caused by register variables not being
preserved (eg. in "object.h" STATIC is defined as register and is turned on
via the AV define in att.h) I made the following patch in "object.h":

================================================================
#if defined (AV) && ! defined (_WIN32)
#error BARFO
#define STATIC  register
#else
#define STATIC
#endif

================================================================
Test configuration 1.

With optimisation set to "-g -O3" (that is, without -fomit-frame-pointers)


maxima ignore-errors  -- NO

"universe.lisp" -- NO

Great: So I let the random tester run for 2800 iterations and although it
did report a couple of errors, they did not crash the the process as has
previously happened - it printed the offending form and then continued with
the next.

================================================================
Test configuration 2.

With optimisation set to "-g -O3 -fomit-frame-pointers":

maxima ignore-errors  -- NO

"universe.lisp" -- FAIL

So no random-tester with this configuration.

================================================================
Test configuration 3.

With optimisation set to "-g -O":

maxima ignore-errors  -- FAIL

"universe.lisp" -- NO

I killed the random tester after 1200 error free iterations.

================================================================

Test configuration 4.

With optimisation set to "-g" (ie --enable-debug):

maxima ignore-errors  -- FAIL

"universe.lisp" -- NO

I had to run with the random tester on 100 iterations.

================================================================
In addition to the "object.h" STATIC patch above, these tests were all done
with the patches I described a few days ago on this list (8M stack,
string.d) so it remains to be seen:

        1. whether other optimisation settings change things (especially
with -fomit-frame-pointer), or

        2. whether the patches from a few days ago can be omitted (I think I 
agree
with Camm that the stack patch is probably a good thing to keep irrespective
of those further results.), and

        3. whether gcc 3.4.0 and 3.3.3 behave any better than previously.


Cheers

Mike Thomas.