FIX BC bug in invokespecial

FIX BC bug in invokespecial

[Andrew Haley]

When we're compiling BC and we see something like 
invokespecial foo.bar(), we search the superclass chain of foo.  We
really shouldn't do that, as it breaks binary compatibility: even if
foo does not have a method bar() at compile time, we should still
generate a reference to foo.bar() and let the runtime system sort it
out.

The right way to fix this is to prevent superclasses from being
searched when BC-compiling.  However, this patch for 4.1 solves the
problem in a simple way by ignoring results from superclasses.  I'll
do something better for mainline: it would be better not to search
superclasses at all.

Andrew.


2006-02-06  Andrew Haley  <aph@redhat.com>

	* expr.c (expand_invoke): (BC mode.)  If we find a method in a
	class other than the one in which we expected to find it, ignore
	the result.

--- gcc/java/expr.c~    2005-12-12 12:14:45.000000000 -0500
+++ gcc/java/expr.c     2006-02-04 05:26:17.000000000 -0500
@@ -2280,6 +2280,14 @@
   else
     method = lookup_java_method (self_type, method_name, method_signature);
 
+  /* We've found a method in a class other than the one in which it
+     was wanted.  This can happen if, for instance, we're trying to
+     compile invokespecial super.equals().  */
+  if (! flag_verify_invocations
+      && method
+      && self_type != DECL_CONTEXT (method))
+    method = NULL_TREE;
+
   /* We've found a method in an interface, but this isn't an interface
      call.  */
   if (opcode != OPCODE_invokeinterface