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

[Mike Thomas]

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.

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

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

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        =


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.