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

[Ethan Swint <eswint.ramu@xxxxxxxxxxx>]

I don't know how well gcc optimizes around jumps - but it looks like 
longjmp restores some of the environment.  Could it be that 'first' is 
being restored to its initial value of '1'?  Try printing the value of 
'first' before the conditional is evaluated. 

It would seem to me that a more suitable workaround would to be to put 
this bit of code in a while or do-while loop - unless you are counting 
on specific bits of the environment being restored to their state when 
setjmp() is called.

-Ethan

Peter Clifton wrote:
> I'm not 100% sure on this one, but I think I've managed to trip over
> what could potentially be a nasty GCC bug.
>
> 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. With my debug code, the function was something like
> this:
>
> static int
> intersect (jmp_buf * jb, POLYAREA * b, POLYAREA * a, int add)
> {
>   POLYAREA *t;
>   PLINE *pa;
>   contour_info c_info;
>   int first = 1;
>
>   printf ("Intersect called\n");
>
>   /* Search the r-tree of the object with most contours
>    * We loop over the contours of "a". Swap if necessary.
>    */
>   if (a->contour_tree->size > b->contour_tree->size)
>     {
>       t = b;
>       b = a;
>       a = t;
>     }
>
>   setjmp (c_info.restart);		/* we loop back here whenever a vertex is inserted */
>   if (first)
>     first = 0;
>   else
>     printf ("Vertex inserted\n");
>
> ....
> }
>
> My printf ("Vertex inserted\n"); is never executed.
>
> I suspect GCC's optimiser mistakenly decides that this code only
> executes once, and that first must be (for all intents and purposes - it
> isn't used elsewhere) constant 1.
>
> The code works if I declare first as: "volatile int first = 1;"
>
> This is tested with GCC (Ubuntu 4.3.3-3ubuntu5) 4.3.3
>
> DJ.. any insight on how to debug this further, or if it is a known
> issue?
>
> 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.
>
> Best wishes,
>
>   


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