This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Patch: Fix for PR java/6520
- From: Tom Tromey <tromey at redhat dot com>
- To: Java Patch List <java-patches at gcc dot gnu dot org>
- Cc: Gcc Patch List <gcc-patches at gcc dot gnu dot org>, Alexandre Petit-Bianco <apbianco at redhat dot com>
- Date: 11 May 2002 19:21:49 -0600
- Subject: Patch: Fix for PR java/6520
- Reply-to: tromey at redhat dot com
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?
Tom
Index: ChangeLog
from Tom Tromey <tromey@redhat.com>
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)