RE: [Gcl-devel] Windows - Instability in universe.lsp

[Mike Thomas]

Hi Camm.

Thanks for the support.

| > | Great!  There are quite a few compiler options, of course, which are
| > | enabled in groups by the -O options.  Pinning down which option causes
| > | the 306th test to fail might be useful at some point.  Likewise if the
| > | 306th test can be made to fail in isolation.  I.e. (load
| > | "gclload1.lsp")(load "file containing failing 306th
| > | test.lsp")(rt:do-tests).  If so, then we can (disassemble...) the
| > | function definition for the failing test and try to get a simple test
| > | case.
| >
| > Sadly my expectation was false and changing the optimisation to
| nothing at
| > all did not make the 306th failure go away.
| >
|
| OK.  Can this test be isolated, with the failure preserved, and serve
| as a test case?

My aim is to do so - the problem is that this is the machine my wife needs
to use, but never-the-less last night I did manage to squeeze in preliminary
tests with each of:

   (-O -fomit-frame-pointers),
   (-Os), and
   no optimisation.

All cases gave the extra failure on that particular machine.

I will try and isolate differences between my day and night computers to see
what is causing the different result.

I will also break the optimisations down into their individual components
per your earlier suggestion.  The above three tests suggest

If your intuition is telling you something about likely individual gcc
optimisation flags or combinations thereof which may cause trouble please
let me know.

There are a lot of different combinations here if we start counting the OS
and hardware as well.


|  My understanding now is that the suite fails to
| complete on stable with the original optimization settings, but does
| complete with one extra failure with -O and below.

Almost - 3.3.1 (but I found out yesterday that MinGW32 gcc 3.3.3 is now
available) - on one computer.

On the other computer exactly the same statement can be made, with the
exception that the extra failure goes away.  I believe that both machines
have exactly the same compilers and tool versions but I am not so sure about
libraries.

So apart from CPU and OS etc (PIII869 NT2000, PIV Win XP), there may still
be other software differences as yet unaccounted for.  That may take some
time to isolate.

|
| > | In general, though, I'm quite happy to proceed to 2.6.2 with -O0 on
| > | mingw if it continues to prove stable, i.e. fixes both ansi issues,
| > | and both maxima issues, particularly compiling maxima with the latest
| > | gcc.  For some as yet only partially understood reason, we are using
| > | -O0 on hppa too.
| >
| > Maxima built and passed all tests by the way - I have yet to
| build a CLtL1
| > compiler and try ACL2.
|
| With latest gcc too?

Yes.

I'm thinking of reverting to 2.95.x for some comparative tests too as I
suspect that gcc 3.* merely brings sloth to the party as far as GCL is
concerned.  3.3.3 is pretty tempting though.


| > | > This falls in the category of thinking too hard close to the
| > | deadline - I
| > | > might be too scared to run the random tester!
| > | >
| > |
| > | Fear not -- my guess is that you'll be in good shape with -O0.
| >
| > OK -O0 is equivalent to no optimisation according to the gcc
| manual by the
| > way.  I'm still gibbering.
| >
|
| This is quite easy to do, and will get easier.  Build a stable ansi
| gcl with debugging preferably, cd into the ansi-tests directory of the
| unstable tree, (load "gclload1.lsp")(compile-and-load
| "random-int-form.lsp")(in-package :cl-test) (loop-random-int-forms
| 1000 8).

You probably missed my earlier note that rt.o hangs on loading in HEAD even
with the optimisation fix.

Hopefully Paul will find the time to back-port to stable.

It would be good if we could report statistics on stability in the actual
release code rather than the HEAD.

It wasn't so much the difficulty of doing it, by the way, but rather the
consequences of finding more bugs - I've entered ostrich, three monkey,
la-la-la, and finger-cross mode.

Cheers

Mike Thomas