Patch: gcj assume-compiled fix

Tom Tromey tromey@redhat.com
Thu Jan 23 19:59:00 GMT 2003


This fixes another -fno-assume-compiled bug.

Suppose you have a class pkg.A with a public final method F.
Now suppose pkg.C extends A.

Now compile B with `-fno-assume-compiled=pkg'.  If B calls F on an
object of type C, gcj will attempt to devirtualize the call (since F
is final).  However, it will try to find F in C's method table, even
though F is declared in A.

The fix to this problem is to use F's context instead of the caller's
notion of where the function might lie.

Ok to commit?

Tom

Index: ChangeLog
from  Tom Tromey  <tromey@redhat.com>

	* expr.c (build_known_method_ref): Use method's context to find
	method table index.

Index: expr.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/expr.c,v
retrieving revision 1.161
diff -u -r1.161 expr.c
--- expr.c 22 Jan 2003 20:53:54 -0000 1.161
+++ expr.c 23 Jan 2003 19:54:54 -0000
@@ -1748,13 +1748,16 @@
 
 	 SELF_TYPE->methods[METHOD_INDEX].ncode
 
-	 This is guaranteed to work (assuming SELF_TYPE has
-	 been initialized), since if the method is not compiled yet,
-	 its ncode points to a trampoline that forces compilation. */
+      */
 
       int method_index = 0;
-      tree meth;
-      tree ref = build_class_ref (self_type);
+      tree meth, ref;
+
+      /* The method might actually be declared in some superclass, so
+	 we have to use its class context, not the caller's notion of
+	 where the method is.  */
+      self_type = DECL_CONTEXT (method);
+      ref = build_class_ref (self_type);
       ref = build1 (INDIRECT_REF, class_type_node, ref);
       if (ncode_ident == NULL_TREE)
 	ncode_ident = get_identifier ("ncode");



More information about the Java-patches mailing list