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

[Peter Clifton <pcjc2@xxxxxxxxx>]

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,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



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