Path: chuka.playstation.co.uk!news
From: alex@teeth.demon.co.uk (Alex Amsel)
Newsgroups: scee.yaroze.programming.gnu_compiler
Subject: Relatively Important(!) : Buggy gcc
Date: Tue, 29 Apr 1997 00:02:14 GMT
Organization: Into Beyond
Lines: 78
Message-ID: <336635d6.3891193@news.playstation.co.uk>
Reply-To: alex@teeth.demon.co.uk
NNTP-Posting-Host: teeth.demon.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Newsreader: Forte Agent .99g/32.335


Right.

In 2 days we have come up with 2 bugs that appear totally compiler
related (though if we ever find anything different we'll let you
know!).

Bug 1
~~~~
When one particular global variable is altered in one particular
function, even though it prints out fine, any functions which use it
are screwed for some reason. But if it is altered anywhere else all is
fine. And if I reset a load of general stuff (nothing to do with this
variable) then all is fine again. Even if I change the variable but
don't use it within this routine, then use it in a later routine, it
still gets screwed up somehow when passed as a parameter to a system
routine yet prints ok. The variable is set very simply - no pointers,
no nothing. The bug fix (at the time; didn't have time to go through
masking loads of code) was to simply mask out the variable modifier
but still use the previous value within the loop. This worked fine,
and the variable was still fine at the end of the function. WEIRD!

Sorry if I haven't explained it well, but it was a weird bug!

Bug 2
~~~~

We had a really weird problem on our little pacman game. The following
structure caused a strange bug, possibly screwing the OT (who knows
what it actually did). An error only occured when accessing a certain
member of the structure at a certain perfectly legitimate point in the
array (and odd location in the array I should add). The error was
certainly ODD I can tell you.

The following structure was used in an array (an even number of items
before someone tells me off for doing something perfectly normal
anyway).  BOOL was defined as a UBYTE, which caused an error, then a
UWORD which also caused an error.  In fact, only by defining it as
ULONG did it work. But again, it only ever went wrong when certain
values were placed within it! It was only XPos that actually had any
problems too, although it was the boolean typedef that seemed to cause
it (even though there are 2 of the damn things!). As with bug 1,
printing the actual modified xpos value showed it be have been updated
correctly. The memory location was all fine, and there were no
apparent clashes with any other data unless the compiler/linker messed
up with global data.

Are ULONGS the only safe thing???? To be quite honest this is pretty
ridiculous. I don't know if the full kit has the same alignment
problems, but from code alledgedly(!) tested there are similar weirdo
flaws in the professional version. Since people pay 10k for this, I'd
be pretty pissed off!! All of a sudden I can forgive slips in game
deadlines and suchlike on the PS-X. These bugs can take a LONG time to
solve.

I should add that Bug 1 alledgedly(!) occured on the full dev kit
although the code for bug 2 has only been run on my Yaroze.

I'm sorry if I sound at all pissed off, but it takes ages to find
these sodding bugs and it is really annoying when it is something so
obscure that should run fine (and does on every other
machine/compiler). And I know it isn't those Yaroze guys fault either.
So please tell me its our code....

FIXEDPOINT is defined as an int BTW, and the array is global.

struct BloodPartical {
	UWORD X, Y;
	BOOL XNeg, YNeg;
	FIXEDPOINT XPos, YPos;
	FIXEDPOINT XVel, YVel;
	FIXEDPOINT XAccl, YAccl;
	ULONG PrevCol;
};

* Alex Amsel * Into Beyond Web Design & JAVA Programming *
* http://www.intobeyond.com  *  WWFC Utter Rubbish 1996-7*
MM - "Steve Corica is every bit as good as that Kinkladze"