Date:	Mon, 24 Apr 1995 04:03:50 -0300 (ADT)
From:	Bill Davidson <bdavidson AT ra DOT isisnet DOT com>
Subject:	Re: More optimization woes...
To:	Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
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 
<sys/farptr.h> 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

- Raw text -