Greetings!
Mike Thomas <address@hidden> writes:
Hi Camm.
Mike wrote:
At midnight I found another problem (again linker/optimisation I think)
mentioned in an earlier email this morning from my home address; which email
seems not to have gotten through to the GCL list.
Camm Maguire wrote:
Details? I think I've missed this.
The testers have been running on OFLAG = O2FLAGS = O3FLAGS = -O3
without incident for long periods now; the only (extremely) stable
combination I have found.
When I add -fomit-frame-pointers to any or all of OFLAG, O2FLAGS or
O3FLAGS, the ANSI test file "rt.o" hangs while loading. Similar
problems if I mix optimisations in those macros.
Setting OFLAG empty, O2FLAGS = -O and O3FLAGS = -O3, for example,
invites disaster. Compiling in -g as well as the optimisation
settings causes a crash later in the test. It seems that the real
problem is in the linker.
So the C compiler optimisation story on Windows is this:
'Then, shalt thou count to three. No more. No less. Three shalt be the
number thou shalt count, and the number of the counting shall be
three. Four shalt thou not count, nor either count thou two, excepting
that thou then proceed to three. Five is right out. Once the number
three, being the third number, be reached, then, releasest thou thine
stable GCL unto the world before thou findest more bugs and, of old
age, thine clients snuff it.'
:-) Does humor grow on the eucalyptus there down under or what?!
Too much..... I've been laughing for hours.
Sounds like your ready. We can and should chase down these
optimization mismatch bugs in the near future, as, uh, they really
shouldn't be there, but if you can get stable ansi and random test
results, and compile the open-source (preferably all three) lisp apps
to pass their tests *on all extant flavors of gcc 3.3* with the same
settings, then I think we are good to go for now. I highlight the gcc
version bit as any sensitivity which shows up with minor gcc
modifications will hit us with high likelihood at the next minor point
release, greatly shortening the lifetime of 2.6.2.
If you don't find random tester errors in the first few thousand runs,
then you most likely won't, as I've run them at the clisp high water
mark level now without failure, and the only difference between our
Linux and Windows ports should be stability, not correctness. Its
very helpful that you've double checked the memory stability under the
new allocation scheme -- thanks! It still would be nice to have Vadim
hammer on it a bit.
I'm going to put in Magnus' block to recursive malloc implementations
tomorrow, and then make a read-only 2.6.2 candidate tag (tomorrow too
most likely) unless you prefer we wait (I'll assume that silence means
no objection :-)). Then for I'm guessing about a week, we should all
collect the results of all tests on exactly the same version on as
many platforms as possible. If there are no show-stoppers, we'll
tabulate the results in a short release-notes doc, and then make the
final 2.6.2 tag with this file alone newly included. Then I'll push
the tarball to ftp.gnu.org, and we can collect binary builds there as
on the temporary site, and be done with it.
I hope I'm not drawing this out too much for the tastes and schedules
of the friends of GCL. I'm most open to other release
ideas/suggestions.
Take care,
Speaking of bugs, the Starlisp simulator is a good test of ANSI
compatibility which GCL fails miserably.
Cheers
Mike Thomas