BugReport for gcj-3.3 java frontend

Fri Mar 12 19:02:00 GMT 2004

Andrew Haley writes:
 > Per Bothner writes:
 > > Erwin Bolwidt wrote:
 > > 
 > > > I found a bug in gcj-3.3.
 > > > ...
 > > > Hopefully this report is useful enough to fix the bug
 > > 
 > > The problem appears to be this calculation in stmt.c:
 > > 
 > > 	range = fold (build (MINUS_EXPR, index_type, maxval, minval));
 > > 
 > > For some reason the overflow bit gets set, enough the index_type
 > > is (32-bit) int, as are teh types of the operands, apparently.
 > > 
 > > Perhaps someone more familiar with fold_const can take a look.
 > 
 > It's very weird. I'm going to look closer.
To my considerable amusement, it's a fix to some of the very first
code I ever wrote in gcj, five years ago.
Andrew.
2004年03月12日 Andrew Haley <aph@redhat.com>
	PR java/14551
	* typeck.c (convert): Clear TREE_OVERFLOW after an integer
	conversion.
Index: gcc/java/typeck.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/typeck.c,v
retrieving revision 1.61
diff -c -2 -p -r1.61 typeck.c
*** gcc/java/typeck.c	4 Feb 2004 19:15:30 -0000	1.61
--- gcc/java/typeck.c	12 Mar 2004 19:01:31 -0000
*************** convert (tree type, tree expr)
*** 138,142 ****
 	return fold (convert_ieee_real_to_integer (type, expr));
 else
! 	return fold (convert_to_integer (type, expr));
 }	 
 if (code == REAL_TYPE)
--- 138,149 ----
 	return fold (convert_ieee_real_to_integer (type, expr));
 else
! 	{
! 	 /* fold very helpfully sets the overflow status if a type
! 	 overflows in a narrowing integer conversion, but Java
! 	 doesn't care. */
! 	 tree tmp = fold (convert_to_integer (type, expr));
! 	 TREE_OVERFLOW (tmp) = 0;
! 	 return tmp;
! 	}
 }	 
 if (code == REAL_TYPE)