Re: [Gcl-devel] STABLE, WINDOWS: read_fasd1() and alloc_relblock()

[Camm Maguire]

Greetings!

Mike Thomas <address@hidden> writes:

> Hi everyone.
> 
> A note of some preliminary but very promising results for anyone
> working on this while I'm asleep tonight:
> 
> Building on the MinGW32 "getc()" function inlining bug (below) I set
> "#define getc fgetc" in "h/mingw.h" which cured the "rt.o" load hang
> but a subsequent crash during "make test-unixport" remained.
> 
> Guessing that the problem afflicting "getc()" might also apply to
> other inlined MSVCRT library functions I set "-fno-inline-functions"
> in the optimisation flags and amazingly got a complete test run with
> mixed optimisation settins.
> 

Definitely a good idea given your other findings.  Great!!

> I class this result as preliminary because my source tree here is
> fairly dirty with debugging printfs and other minor "trial and error"
> changes left over from the past fortnight and also because I have yet
> to test Maxima et al with the fix.
> 
> There remains:
> 
>    1. the zero byte alloc_rel_block question and
> 

Looked into this and it is normal.  Gensym in particular makes a
symbol with a name temporarily set equal to the empty string.  You of
course should never see negative values here :-).

>    2. whatever crashes remain when these fixes are tested on compiling
> applications and the random tester (eg Maxima path troubles etc),
> 

What is the status with gcc 3.3.3 and gcl/maxima, for example?


> however I think this is a good step forward as the new optimisation
> flags in CVS are, until testing dictates otherwise:
> 
> 
> CFLAGS       = -O3 -fomit-frame-pointer -fno-zero-initialized-in-bss
> -fno-inline-functions -mms-bitfields -Wall -fwritable-strings
> -DVOL=volatile -fsigned-char $(PROCESSOR_FLAGS) -I$(GCLDIR)/o
> FINAL_CFLAGS = -fno-zero-initialized-in-bss -mms-bitfields -Wall
> -fwritable-strings -DVOL=volatile -fsigned-char $(PROCESSOR_FLAGS)
> O3FLAGS      = -O3 -fomit-frame-pointer -fno-inline-functions
> O2FLAGS      = -O -fno-inline-functions
> OFLAG        =
> 

Wonderful!!  What is OFLAG?  I just see *opt-three* and *opt-two* in
the compiler package.

Take care, and thanks for your fantastic work here.  Am especially
interested in the latest gcc/gcl/maxima combo results.  But perhaps
I'm setting the prioritites incorrectly -- if there are bugs of the
order of the getc issue you've discovered still in the gcc compiler,
then perhaps it is too hasty to conclude that the crash of the above
combination is gcl's fault.  Do you have a sense of the stability of
gcc 3.3.3 on mingw in general?  we should at least be set with gcc
3.3.3 with all optimzation turned off, no?

Take care,

> 
> Cheers
> 
> Mike Thomas.
> 
> 
> Mike Thomas wrote:
> > Hi all.
> > On the weekend I wrote:
> > | PART 1: read_fasd()
> > |
> > | I happened on a combination of gcc optimisation flags which gave a
> > | repeatable hang on Windows in read_fasd1 (o/fasdump.c) while loading
> > | ansi-tests/rt.o.
> > |
> > | It turns out that the local variable "leng" in that function declared as
> > |   "int" receives an erroneous result from "getc()" via the GETD macro
> > | while reading the fasd data appended at the end of "rt.o":
> > |
> > |        case DP(d_short_string:)
> > |   fprintf ( stderr, "rf1 d_short_string, byte i = %x\n", i );
> > |   leng=GETD("leng=%d");
> > |   fprintf ( stderr, "rf1 leng = %d\n", leng );
> > |   leng = LENGTH(i,leng);
> > |   fprintf ( stderr, "rf1 Before READ_STRING, leng = %d\n", leng );
> > |   READ_STRING(leng,loc);
> > |   fprintf ( stderr, "rf1 After READ_STRING\n" );
> > |   return;
> > |
> > | The erroneous result is -122 which really should be 134 (134 + 122 =
> > | 256).  Redeclaring "leng" as "unsigned char" fixes that immediate
> > | problem but a crash occurs later anyway so presumably there are other
> > | places where such problems may be occurring.
> > |
> > | I suppose that this could be some interaction between the mixed
> > | optimisation settings and the "-fsigned-char" compiler flag and possibly
> > |   even the GCL custom linker.  Perhaps the C linker would normally do
> > | stuff to help optimise across module boundaries and seamlessly connect
> > | functions which have been optimised differently which our linker doesn't?
> > Having searched the MinGW32 mailing list, it turns out that this is
> > a known
> > bug in MinGW32 runtime version 3.2 "getc()":
> >    http://sourceforge.net/mailarchive/message.php?msg_id=6311360
> > At this stage I don't know whether it applies to earlier versions of
> > the
> > runtime but I would assume so.
> > Unfortunately 3.2 is the current version of the MinGW32 runtime.
> > I'll make
> > some enquiries.
> > Cheers
> > Mike Thomas.
> >
> 
> 
> 
> 

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