This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[ecj] vtable entries for bridge methods
- From: Andrew Haley <aph at redhat dot com>
- To: java-patches at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Fri, 8 Sep 2006 18:32:00 +0100
- Subject: [ecj] vtable entries for bridge methods
We weren't distinguishing return types when building vtables, but the
VM does so distinguish: for example, T.foo()bar is a different method
from T.foo()Object, and we need vtable slots for both of them.
Because we weren't using the return type when searching vtables, we
were only building a vtable entry for the first one we saw.
Arguably this is also a bug in mainline, but it really only affects
generic code and bytecode written in languages other than Java.
Andrew.
2006-09-08 Andrew Haley <aph@redhat.com>
* class.c (layout_class_method): Use build_java_signature, not
build_java_argument_signature. Use lookup_java_method, not
lookup_argument_method.
Index: class.c
===================================================================
--- class.c (revision 116634)
+++ class.c (working copy)
@@ -2476,15 +2476,15 @@
p = ptr;
}
DECL_CONSTRUCTOR_P (method_decl) = 1;
- build_java_argument_signature (TREE_TYPE (method_decl));
+ build_java_signature (TREE_TYPE (method_decl));
}
else if (! METHOD_STATIC (method_decl))
{
tree method_sig =
- build_java_argument_signature (TREE_TYPE (method_decl));
+ build_java_signature (TREE_TYPE (method_decl));
bool method_override = false;
- tree super_method = lookup_argument_method (super_class, method_name,
- method_sig);
+ tree super_method = lookup_java_method (super_class, method_name,
+ method_sig);
if (super_method != NULL_TREE
&& ! METHOD_DUMMY (super_method))
{