This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Patch: Fix for PR java/6520

This patch fixes PR java/6520.

In some cases fold() was changing the type of the node we passed to
it.  If this node was a shared constant, then the constant's type
would change, causing confusion.  In this PR the confusion manifested
as invalid bytecode.

This patch rebuilt libgcj and Mauve, passed the test suite, and fixed
the problem in question.  Ok to commit?  Or is there another approach?
Are there other places we'll have to protect against this problem?


Index: ChangeLog
from  Tom Tromey  <>

	Fix for PR java/6520:
	* typeck.c (convert): Copy some nodes before conversion.

Index: typeck.c
RCS file: /cvs/gcc/gcc/gcc/java/typeck.c,v
retrieving revision 1.48
diff -u -r1.48 typeck.c
--- typeck.c 18 Apr 2002 17:54:09 -0000 1.48
+++ typeck.c 11 May 2002 22:29:01 -0000
@@ -129,6 +129,13 @@
     return error_mark_node;
   if (code == VOID_TYPE)
     return build1 (CONVERT_EXPR, type, expr);
+  /* A constant might be shared, and converting it may change the
+     underlying type.  That can confuse the bytecode generator, so we
+     make a copy before conversion.  */
+  if (TREE_CODE_CLASS (TREE_CODE (expr)) == 'c')
+    expr = copy_node (expr);
   if (code == BOOLEAN_TYPE)
     return fold (convert_to_boolean (type, expr));
   if (code == INTEGER_TYPE)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]