gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] trying to finalize the windows issues ...


From: Camm Maguire
Subject: Re: [Gcl-devel] trying to finalize the windows issues ...
Date: 29 May 2004 15:25:54 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

"Mike Thomas" <address@hidden> writes:

> Hi there.
> 
> | 1) I thought we still had problems with >=3.3.3 vs. 3.3.1, no?  In
> |    general, I'm afraid I'm a bit behind on the latest status and could
> |    really use a complete summary of known bugs.
> 
> Putting aside gcc 3.4.0 for now (as it is the pending release I had hoped it
> might solve problems for us but, really, I think the problem is GCL rather
> than the compiler), there are three GCL runtime bugs for which I am
> consciously seeking causes:
> 
> 1.  "Maxima ignore-errors" - does not have effect with Maxima unless the
> source in defsystem.lisp is deliberately altered to give it effect, of
> course,
> 
> 2.  "ANSI test universe.lsp load" - this results at high optimisation
> levels.
> 
> 3.  Instability in the ANSI tester.
> 

Segfaults here (in 3) or spurious errors properly reported?

Its rather clear to me that 2 is due to a gcc optimization bug on
mingw.  I suggest all further image consideration be confined to
optimization levels below that triggering this issue.  

> Various builds (different combinations of compiler optimisation and various
> patches such as your recent patches + the stack hack set out below) exhibit
> one or more of these problems.  For a given patch, changing the compiler
> optimisation results in swapping about of the particular bug being
> expressed.

OK, I think we should take the position that a bug that is introduced
on increasing optimzation can be a real compiler or code issue, but
one that disappears on increasing optimzation is simply a fortuitous
masking.  from this perspective, 1 is not 'swapped out' by any
optimzation flag setting I've yet seen reported, as it appears with
--enable-debug.  the stack adjustment, on the other hand, appears to
eliminate 1 at all optimzation settings, and appears to be independent
of the other two, not the least in its being untrappable, unlike 2 and
3.  So again, unless there are compiler version issues with 3.3.3 and
3.4.0, I think we should put in the 8Mb stack and decrease the
optimzation to eliminate 2.  In such an image, we might want to then
analyze what happens to 3.

> 
> Another patch which I have found stops the ignore-errors bug (with CVS
> default optimisation flags) is to insert a vs_reset just before the final
> return after the "vs_popp()" in "string.d", the function
> "coerce_to_string()".  Unfortunately this then gives the "universe.lsp" bug
> and changes in optimisation settings reverses the problem.
> 

Does the vs_reset fix the ignore-erros issue with --enable debug (I
doubt this, but it would be interesting)?  If not, its effect is an
accident almost surely. This bug is already known to be maskable.  the
stack change is the only change of which I am aware that removes it at
all opt levels.  What you write above is consistent with the
hypothesis of two non-interacting bugs, one of which is compiler
optimization induced, repeatable and trappable, the other of which is
erratic and only disappears reliably with a bigger stack.

> Likewise you may recall my optimism recently over patching one of the
> "pathname.d" functions to (in theory) switch off interrupts or some such.
> 

Again, there does not appear to be evidence here that these have any
effect on the ignore-erros issue at all opt levels, unlike the stack
change. 

> 
> |
> | 2) Having a build fail with an extended stack should give us a clue?
> |    How are you extending the stack, and how does it fail?
> 
> In configure.in:
> 
> TCFLAGS="-Wl,--stack=8388608 -Wall -DVOL=volatile -fsigned-char"
> 
> and a similar linker directive in unixport/Makefile when building the raw_*
> executable.
> 
> In o/main.c:
> 
>           _stacktop    = _stackbottom - 8388608; // ???
> 
> The number 8388608 = 1024x1024x8.
> 
> This method is messy as all Lisp compile commands spew a warning about the
> resulting unused linker script.

It would be helpful to post this warning.  Perhaps can be turned off
selectively with a -W option.

Take care,

> 
> Cheers
> 
> Mike Thomas.
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]