[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: PCB Polygon code (with r-tree speedups) triggers GCC bug...



> I don't know how well gcc optimizes around jumps - but it looks [as
> though] longjmp restores some of the environment.  Could it be that
> 'first' is being restored to its initial value of '1'?

>> I've been testing the polygon intersection code, which uses a setjmp
>> / longjmp pair to short-circuit a large multi-function loop whenever
>> a new vertex is inserted.  [...]

>>   int first = 1;

>>   setjmp (c_info.restart);		/* we loop back here whenever a vertex is inserted */
>>   if (first)
>>     first = 0;
>>   else
>>     printf ("Vertex inserted\n");

>> The code works if I declare first as: "volatile int first = 1;"

This is the correct fix.  Auto objects which get changed between the
setjmp and the longjmp are indeterminate after the longjmp, unless they
are declared volatile.  In the words of one setjmp(3) manpage I have at
ready hand:

     All accessible objects have values as of the time longjmp() routine was
     called, except that the values of objects of automatic storage invocation
     duration that do not have the volatile type and have been changed between
     the setjmp() invocation and longjmp() call are indeterminate.

This is perhaps annoying, but it's how longjmp works.

>> I'm quite concerned that if GCC is messing this case up, there might
>> be other non-debugging pieces of code which are functionally
>> affected by the problem.

GCC is not messing it up, except to the extent that revealing a bug in
the code constitutes that.  Code that depends, after longjmping, on
non-volatile auto data which gets changed between the setjmp and the
longjmp simply is buggy, even if one or another compiler doesn't happen
to make the bug manifest.

That there might be other, similarly buggy, pieces of code _is_ quite
likely something worth looking into, though.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@xxxxxxxxxxxxxxxxxxxx
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user