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

[Mike Thomas]

Hi Camm.

Thanks for your reply.  Outlook gave me an incoming mail blockage this
morning and only just received it.


| My guess is that getc is returning char on Windows, in which case we
| have some serious work.  Can you please confirm?

"getc()" on Windows is the same (ie int) .  See my other email; it is
apparently a known runtime bug caused by inline optimisation of getc().

Since that email, I read that the MinGW32 team is tentatively planning a new
stable release of the tools and libraries (hopefully includes the fix to our
particular bug which is currently in CVS) by mid-May.

If the worst comes to the worst we could release GCL 2.6.2 shortly and then
after the new MinGW32 release I would make another installer.

We could write a temporary replacement "getc()" on Windows and include it
with the release.  Hopefully tonight.


| BTW, if this is an issue (setq compiler::*default-system-p* t) should
| be a workaround.  (Sidesteps the fasl, data is read in as fully
| written out lisp code.  (setq compiler::*default-data-file* t) to
| confirm).

I can't test this at the moment; again hopefully tonight.


| > 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?
| >
|
| What settings are we talking about?  One of them apparently tries to
| optimize the getc call.  I doubt the linker is implicated here --
| please correct me if I'm missing something.

You are correct.  If memory serves the settings were O2FLAGS = -O2, O2FLAGS
= -O3, CFLAGS = ...-O3 -fomit-frame-pointer... .

Cheers

Mike Thomas.