[Bug c/44681] New: usage of macro in loop boundary leads to crash

2010-06-26 Thread jd at cococo dot de
When porting my software from Win32 to Linux, i had to recompile it with gcc
under Mingw and also under Linux. There was a hurdle, because the loop shown
below in b) crashed after a while on both platforms. (I was happy to find the
location of the bug with gdb!) After rearranging the code like c) it worked
properly.
Sorry, but i am not able to provide test data. Maybe someone will see at once,
where the problem is located.

Greetings
Jens
http://cococo.de

a) prerequisite
#define max(a,b)a>b?a:b

b) buggy variant (for loop in line 13)
//--
//copy column left to right
//--
void copyvector(Tree pre,Tree left,int lc,Tree right,int rc) {
  int nr;
  callsofcopyvector++;
  //check initialization of precondition
  defval(left,right,rc,coeff(left,0,lc));
  right->functype=left->functype;
  right->bordertype=left->bordertype;
  right->symtype=left->symtype;
  right->reversive=left->reversive;
  for (nr=0;nr <= max(left->rows,right->rows);nr++) {//now do composition of
functions
 if (nr <= right->rows)
asg(right,nr,rc,0);
 if ((nr <= left->rows) && (nr <= right->rows)) {
Tree ur=coeff(left,nr,lc);
//debug(coeff(left,nr,0))
asg(right,nr,rc,ur);
 }
  }
  asg(right,0,rc,pre);
  checkunreachable(right,right,rc);
  return;
}
c) working variant
//--
//copy column left to right
//--
void copyvector(Tree pre,Tree left,int lc,Tree right,int rc) {
  int nr,mav=max(left->rows,right->rows);
  callsofcopyvector++;
  //check initialization of precondition
  defval(left,right,rc,coeff(left,0,lc));
  right->functype=left->functype;
  right->bordertype=left->bordertype;
  right->symtype=left->symtype;
  right->reversive=left->reversive;
  for (nr=0;nr <= mav;nr++) {//now do composition of functions
 if (nr <= right->rows)
asg(right,nr,rc,0);
 if ((nr <= left->rows) && (nr <= right->rows)) {
Tree ur=coeff(left,nr,lc);
//debug(coeff(left,nr,0))
asg(right,nr,rc,ur);
 }
  }
  asg(right,0,rc,pre);
  checkunreachable(right,right,rc);
  return;
}


-- 
   Summary: usage of macro in loop boundary leads to crash
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: blocker
      Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jd at cococo dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44681



[Bug middle-end/44681] usage of macro in loop boundary leads to crash

2010-06-30 Thread jd at cococo dot de


--- Comment #3 from jd at cococo dot de  2010-06-30 10:32 ---
You are right - it was a matter of bracketing. After having changed the macro
to
  #define max(a,b)(a>b?a:b)
it works fine on MingW and Linux.

The problem lies in an incompatibility between to Delphi 2010. Delphi processed
it according to my intention and gcc interprets it differently.

Thanks,
Jens 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44681



[Bug middle-end/44681] usage of macro in loop boundary leads to crash

2010-06-30 Thread jd at cococo dot de


--- Comment #5 from jd at cococo dot de  2010-06-30 13:43 ---
Which is the standard C operator precedence? It should not depend on the
dialect. Is there a pragma for it?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44681



[Bug middle-end/44681] usage of macro in loop boundary leads to crash

2010-06-30 Thread jd at cococo dot de


--- Comment #7 from jd at cococo dot de  2010-06-30 16:47 ---
Sorry, I was not precise enough. Delphi is the IDE for both, Pascal and C, and
what I meant by the word are the language(s) Borland C and C++. They have an
option for Standard C. Maybe I misunderstood it ... 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44681



[Bug middle-end/44681] usage of macro in loop boundary leads to crash

2010-06-30 Thread jd at cococo dot de


--- Comment #9 from jd at cococo dot de  2010-07-01 05:37 ---
Ok, but in terms of semantics there is only one way of interpreting the
sentence

  nr <= left->rows > right->rows ? left->rows : right->rows

because we have to differ between conditions yielding truth values and
expressions yielding numbers. So from a domain theoretic point of view I
assumed it to be

  nr <= ((left->rows > right->rows) ? left->rows : right->rows)

Have a nice day,
Jens


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44681