[Top][All Lists]

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

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

From: Mike Thomas
Subject: Re: [Gcl-devel] STABLE, WINDOWS: read_fasd1() and alloc_relblock()
Date: Mon, 19 Apr 2004 14:55:49 +1000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

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        =


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()":


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.


Mike Thomas.

reply via email to

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