Date: Mon, 24 Apr 1995 04:03:50 -0300 (ADT) From: Bill Davidson Subject: Re: More optimization woes... To: Stephen Turnbull Cc: djgpp AT sun DOT soe DOT clarkson DOT edu On Sun, 23 Apr 1995, Stephen Turnbull wrote: > Does it work correctly under gdb and without debugging? If so, the > chance that it's edebug (which is djgpp-specific) rises drastically. I don't think I tried it under gdb; depends what you mean by "without debugging". If you mean "not running under a debugger", I tried that first and it crashed with a segmentation violation. If you mean "compiled without debugging info (no -g)", no, I've been busy tracking down a few bugs and haven't tried that. Pity what you say about about edebug32; it's not as powerful as gdb, and not as pretty as ladybug, but I like the interface for quick-and-dirty debugging. (Why do I have more debuggers than compilers?) > > The compiler is *not* allowed to move any following references to > wnd->ct before this line. Look at the assembler output when compiled > with and without optimization. (You can isolate the whole function in > a separate file so it's the only one; to see the assembler, use "gcc > -S" (that's an upper-case 'S'; I believe the output from file.c ends > up in file.i by default but I'm not sure). I believe it ends up in file.s; I haven't done this yet. > You have checked that DFmalloc() is not in fact producing a NULL > pointer for some reason, I assume. But if it were me, the assumption > might be false---last head-scratcher that bit me was very similar :-) Shortly after posting my message, I realized that there was a simple work-around (I promise that in future I will think _before_ I post!). I just enclosed the line wnd->ct = DFmalloc(...); in an if(), and that forced the compiler to issue the call and evaluate the result before dereferencing the pointer. No NULL returns, and no segmentation violations. I will happily stipulate that the problem arose because of bad programming practice (failing to check the return value of a function returning a pointer... kids, don't try this at home!), especially since it is code I am porting, not writing! I would never write a call to malloc() without testing the result before using it, but I trusted someone else's code that effectively did the same thing because, well, it was someone else's code. However, the "optimization" encountered here is pretty weird, and I am pretty sure the generated code was as I described because: 1) it caused a segmentation violation when _not_ running under the debugger (that's why I used the debugger!), and 2) the simple fix outlined above worked, and never reported a NULL return value from DFmalloc(). For the compiler to move the assignment to wnd->ct _after_ the use of it is unforgiveable (bad coding not withstanding), and when I get a chance I will explore it more fully. I am also quite sure that, if the problem is as real as I think it is, it is a gcc/FSF problem. I wonder if the fact that the assignment was to a structure member referenced *via a pointer*, as opposed to a local or global variable, makes a difference. Last week when I described problems with functions, someone (can't remember his name) sent me a message describing a problem he had using inline asm() functions that involved multiple levels of pointer dereferencing. Not the same, but there might be a common thread. *Sigh* When I finally get the program working I might take some time to run some tests and explore these issues, but right now my highest priority is getting working code! Thanks for the help (as always)! Bill Davidson bdavidson AT ra,isisnet.com