This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: BugReport for gcj-3.3 java frontend
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)