This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
FIX BC bug in invokespecial
- From: Andrew Haley <aph at redhat dot com>
- To: java-patches at gcc, gnu dot org at zapata dot pink, gcc-patches at gcc dot gnu dot org
- Date: Mon, 6 Feb 2006 12:44:33 +0000
- Subject: FIX BC bug in invokespecial
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