delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/06/08/10:49:05

From: Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Weird Optimisation thingies to do with Allegro in this case
Date: Sun, 8 Jun 1997 14:05:57 +0100
Organization: None
Distribution: world
Message-ID: <rvm5POA14qmzEwi0@talula.demon.co.uk>
References: <33997160 DOT 469197 AT news DOT btinternet DOT com>
NNTP-Posting-Host: talula.demon.co.uk
MIME-Version: 1.0
Lines: 53
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Thomas Harte writes:
>       I have a nearly finished game, which compiles and runs fine
>normally. However, if I compile with -O1, -O2 or -O3 (haven't tried
>any others) I get screens of number such as :-

There are any number of things that this could be (stray pointer
references, use of uninitialised variables, etc, can all have very
different effects depending on the optimisation level), but one obvious
thing occurs to me that would be worth checking: have you recently
installed any work-in-progress versions of Allegro on top of your copy
of v2.2? If you do this, rather than using a clean directory, it is
possible that some files may not get recompiled, because if you built
your copy of 2.2 more recently than I made some changes to my post 2.2
files, make fails to realise that the files need rebuilding. Also, check
that the allegro.h being included by your program (the one in
djgpp/include/), is from the same Allegro version as your liballeg.a.
The reason I mention this is that I recently added a lot of new pointers
to the virtual function table in the BITMAP structure, which can cause
problems if you are mixing files from different versions and compiling
with optimisation (without -O, the wrapper functions don't get inlined,
so the version conflict wouldn't have such a drastic effect).

>Call frame traceback EIPs:
>  0x000022d8
>  0x0000188f
>  0x0001adb2
>
>       And all the traceback thingies lead to is obviously not bugged
>lines such as :-

One possibility is that it could actually be crashing inside an Allegro
function, but because Allegro is compiled with the -fomit-frame-pointer
flag, symify is failing to realise this. If you set the environment
variable "DEBUGMODE=1", delete the contents of allegro/obj/djgpp/, and
rebuild Allegro, you'll get a liballeg.a that runs at about 1% the usual
speed, but will contain full debug info for all the Allegro routines so
you can see whether this is the case...

>       . . . can anyone tell me the error? Is it that I am storing a
>floating point number in an integer? Usually this just rounds it off,

That certainly isn't it: float <-> int conversions are quite safe. You
could add a cast to make it explicit, but that wouldn't actually have
any effect: the compiler does that automatically...

The only time this could cause an error is if the float is too big to
fit in the range of an int, but that would raise an FPU exception, not a
GPF...


--
Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
Beauty is a French phonetic corruption of a short cloth neck ornament.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019