From:	Mark Hull-Richter <mhr AT sparc DOT SanDiegoCA DOT ATTGIS DOT COM>
Subject:	Odd behavior in djgpp-compiled program
To:	djgpp AT sun DOT soe DOT clarkson DOT edu (DJGPP Mailing List)
Date:	Tue, 28 Feb 1995 23:45:19 -8000 (PST)

First, let me state that I am delighted to have finally found a C-compiler
that actually creates an executable under MS-DOS from a source I have used on
four different Unix platforms for several years now.  The program is a pseudo-
randomizer that generates a particular kind of role-playing character for a
game I wrote.  The source is around 7k lines and runs fine under Unix and,
more or less now under DOS as well.  (This is something neither Turbo C v2.0
nor Borland C++ v2.0 could do for me - too many really bizarre run time
crashes.)

The problem I am seeing is that tiny changes in the source which have no
effect (except the ones I intend to create) on Unix cause major upchucks under
MS-DOS with the DJGPP compiler-make-run-time.  The most recent change I made
was to display one field, tracked internally as an integer (ok, byte) in the
form x.yy (where x = field / 100 and yy = field % 100 formatted %02d).  This
_should_ make absolutely no difference in what the program does, but the
difference is major.

There is a particularly complex character type that creates a larger amount of
randomization and output than the others.  This type, with the new executable,
causes the oddball run-time error of either "Unsupported INT 0x0c" or
"Segmentation violation in pointer 0x00000000 at d8:0".  Either way, I usually
also see a segmentation violation in the traceback as well.

So, I thought, well I'll just compile it with -g instead of -O and debug it.

Wrong.  With the -g flag set instead of -O, the program behaves perfectly.  In
fact, if I force-feed the debug and optimized (i.e., non-debug) versions the
same seeds, the debug version works perfectly on the seeds that kill the
optimized version, and the optimized version blows up with seeds that the
debug version digests very nicely.

I'm puzzled - how do I find the problem with the optimizer, short of a
full-blown code analysis, which would be a real pain?  What should I look for
that might be getting optimized too well?  It's a sore point since the
optimized version is only 156,590 bytes after coff2exe, whereas the debug
version is 360,448 (after coff2exe).  I'd rather be able to run the slimmer,
faster version, but with the same steady consistency (and lack of errors) I
now get with the debug version.

Incidentally, I had a similar problem after I upgraded to patch 1.12m4, but
then I also re-downloaded the 1/31/95 gcc and the problem went away,
temporarily.  I thought there might be a relationship there, but now I dunno.

I use the library functions randoms() and random() at present - they seem to
be good enough for what I need.  (BTW, the Unix source uses srand48 and
lrand48 instead, but I doubt that this would make that much difference in this
particular situation.)

I am currently running with the following sets of files (as shown by an ls -l
in my Unix system's download directory at work):

	-rw-r-----  1 mhr       1004073 Jan 26 10:34 bnu252bn.zip
	-rw-r-----  1 mhr        805698 Jan 26 10:42 dj112m1.zip
	-rw-r-----  1 mhr         79558 Jan 26 10:43 dj112m2.zip
	-rw-r-----  1 mhr        168908 Jan 26 10:46 dj112m3.zip
	-rw-r-----  1 mhr         49707 Feb 13 12:34 dj112m4.zip
	-rw-r-----  1 mhr        462241 Jan 26 09:51 djdev112.zip
	-rw-r-----  1 mhr        224477 Jan 26 09:56 djdoc112.zip
	-rw-r-----  1 mhr        120681 Jan 26 09:57 djeoe112.zip
	-rw-r-----  1 mhr         45689 Feb 13 12:31 faq100.zip
	-rw-r-----  1 mhr        628956 Feb 22 10:55 gcc263bn.zip
	-rw-r-----  1 mhr        853230 Feb 22 11:09 gcc263dc.zip
	-rw-r-----  1 mhr        102124 Feb  2 11:47 mak371bn.zip
	-rw-r-----  1 mhr        153701 Feb 13 12:31 txi310bn.zip
	-rw-r-----  1 mhr        378420 Feb 22 11:21 txi310dc.zip

Please send all replies to ME and DO NOT repeat NOT cc the mailing list.  I
will summarize the results and post them later.  Thank you.

-- 
 ++==     AT&T   Mark A. Hull-Richter, Consulting Engineer  (310)524-5782 voice
+GIr==   Global  Teradata Decision Enabling Systems Center   427-5782 VoicePlus
=++=== Information  100 North Sepulveda Boulevard, #17-259  (310)524-5517 FAX
 ====   Solutions   El Segundo, CA  90245       mhr AT sparc DOT SanDiegoCA DOT ATTGIS DOT com

- Raw text -