Re: [Gcl-devel] 2.6.2.....

[Camm Maguire]

Greetings!

Mike Thomas <address@hidden> writes:

> Hi Vadim/Camm.
> 
> >>> Unfortunately Maxima build ignore-errors bug is still here.
> >>>
> >>
> >>
> >> Argh!  I was banking on the hope that the ansi-crash and this bug
> >> were manifestations of the same thing.  Are we all sure we are using
> >> the same carefully balanced compiler optimization options?
> 
> I just used a standard CVS stable GCL set of optimisation settings
> with gcc 3.3.1/binutils 2.14.90.
> 
> 
> >>  Mike, can
> >> you reproduce?
> 
> And yes, I reproduced it.
> 
> I just put some print statements in the offending function and got a
> similar problem in a different location as follows:
> 
> .....
> ;        - Compiling source file
> ;          "c:/cvs/head/maxima/src/numerical/slatec/xerprn.lisp"
> "binary-gcl"
> ""
> #p"binary-gcl"
> #p""
> "binary-gcl"
> NIL
> ""
> "binary-gcl/"
> "numerical/slatec/xerprn"
> #p"binary-gcl/"
> #p"numerical/slatec/xerprn"
> ""
> NIL
> ""
> Compiling c:/cvs/head/maxima/src/numerical/slatec/xerprn.lisp.
> End of Pass 1.
> End of Pass 2.
> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
> Finished compiling binary-gcl/numerical/slatec/xerprn.o.
> 
> ;        - Loading binary file "binary-gcl/numerical/slatec/xerprn.o"
> Loading binary-gcl/numerical/slatec/xerprn.o
> start address -T 105c5248 Finished loading
> binary-gcl/numerical/slatec/xerprn.o
> 

A few thoughts:

1) It looks like the problem starts here, is there a carriage return
   at the front of the filename?

2) Can you please run with (setq si::*notify-gbc* t)?  The erratic
   nature of the problem indicates that it is possible that some windows
   specific code is holding on to a pointer to a relocatable piece of
   memory across a GBC call.  I had suspected fix_filename, but it
   does not appear that there are any allocs in there.

3) Is the problem always triggered on a source .lsp file when
   compiling, or does it ever first appear when loading a .o?

4) Is the gcc 3.3.3 maxima compile issue gone?  If so, my
   understanding is that this is the last of the three original
   problems, 2 of which were ansi test failures in head and stable,
   and one of which was maxima compile failure with gcc 3.3.3.

Thanks again for all your wok on this.

Take care,


> #p"c:/cvs/head/maxima/src/"
> ""
> #p"c:/cvs/head/maxima/src/"
> #p""
> ""
> ("c:")
> ""
> "c:/cvs/head/maxima/src/"
> "numerical/slatec/xersve"
> #p"c:/cvs/head/maxima/src/"
> #p"numerical/slatec/xersve"
> ""
> ("c:")
> ""
> ;        - Source file not found. Not compiling file
> ;
> "c:/cvs/head/maxima/src/c:/cvs/head/maxima/src//numerical/slatec/xersve.lisp"
> "binary-gcl"
> ""
> #p"binary-gcl"
> #p""
> "binary-gcl"
> NIL
> ""
> "binary-gcl/"
> "numerical/slatec/xersve"
> #p"binary-gcl/"
> #p"numerical/slatec/xersve"
> ""
> NIL
> ""
> ;        - Source file
> ;
> c:/cvs/head/maxima/src/c:/cvs/head/maxima/src//numerical/slatec/xersve.lisp
> ;          and binary file binary-gcl/numerical/slatec/xersve.o not
> found, not
> ;          loading.
> Source file
> "c:/cvs/head/maxima/src/c:/cvs/head/maxima/src//numerical/slatec/xersve.lisp"
> and binary file "binary-gcl/numerical/slatec/xersve.o" do not exist.
> 
> Fast links are on: do (use-fast-links nil) for debugging
> Broken at WHEN.  Type :H for Help.
>   1 (Continue) Continue, ignoring missing files.
>   2 (Abort) Return to top level.
> dbl:>>
> 
> 
> 
> 
> 

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