From: Mark Hull-Richter 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