From: Shawn Hargreaves 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: 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 Precedence: bulk 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.