This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
PR/17845: looking for a superclass in the wrong package
- From: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- To: Ranjit Mathew <rmathew at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, java-patches at gcc dot gnu dot org
- Date: Thu, 19 May 2005 12:04:15 +0200
- Subject: PR/17845: looking for a superclass in the wrong package
- References: <d6h956$i6o$1@sea.gmane.org> <428C431D.9020600@lu.unisi.ch> <39399b9d050519025970a8861@mail.gmail.com>
The patch removes a path for looking a superclass that seems bogus to
me. gcj would try every package name defined so far, which depends on
the files on the command line, and has no correspondance in the JLS.
Ranjit Mathew tested the patch for me:
FWIW, I tested your patch for PR17845 by doing a clean
bootstrap and running the entire libjava testsuite (including
Jacks) and found no regressions on i686-pc-linux-gnu.
I tested it without jacks on powerpc-apple-darwin. Ok for mainline?
Paolo
2005-05-19 Paolo Bonzini <bonzini@gnu.org>
PR java/17845
* parse.y (register_package, package_list): Remove.
(package_declaration): Do not call register_package.
(do_resolve_class): Do not use package_list.
Index: parse.y
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/parse.y,v
retrieving revision 1.533
diff -p -u -r1.533 parse.y
--- parse.y 10 May 2005 13:23:35 -0000 1.533
+++ parse.y 19 May 2005 07:40:38 -0000
@@ -113,7 +113,6 @@ static int find_in_imports_on_demand (tr
static void find_in_imports (tree, tree);
static void check_inner_class_access (tree, tree, tree);
static int check_pkg_class_access (tree, tree, bool, tree);
-static void register_package (tree);
static tree resolve_package (tree, tree *, tree *);
static tree resolve_class (tree, tree, tree, tree);
static void declare_local_variables (int, tree, tree);
@@ -408,9 +407,6 @@ static GTY(()) tree current_static_block
/* The generated `write_parm_value$' identifier. */
static GTY(()) tree wpv_id;
-/* The list of all packages we've seen so far */
-static GTY(()) tree package_list;
-
/* Hold THIS for the scope of the current method decl. */
static GTY(()) tree current_this;
@@ -738,7 +734,6 @@ package_declaration:
PACKAGE_TK name SC_TK
{
ctxp->package = EXPR_WFL_NODE ($2);
- register_package (ctxp->package);
}
| PACKAGE_TK error
{yyerror ("Missing name"); RECOVER;}
@@ -5970,22 +5965,6 @@ do_resolve_class (tree enclosing, tree i
if ((new_class_decl = IDENTIFIER_CLASS_VALUE (TYPE_NAME (class_type))))
return new_class_decl;
- /* 5- Try with a name qualified with the package name we've seen so far */
- if (!QUALIFIED_P (TYPE_NAME (class_type)))
- {
- tree package;
-
- /* If there is a current package (ctxp->package), it's the first
- element of package_list and we can skip it. */
- for (package = (ctxp->package ?
- TREE_CHAIN (package_list) : package_list);
- package; package = TREE_CHAIN (package))
- if ((new_class_decl = qualify_and_find (class_type,
- TREE_PURPOSE (package),
- TYPE_NAME (class_type))))
- return new_class_decl;
- }
-
/* 5- Check another compilation unit that bears the name of type */
load_class (TYPE_NAME (class_type), 0);
@@ -7247,27 +7226,6 @@ find_in_imports_on_demand (tree enclosin
return (seen_once < 0 ? 0 : seen_once); /* It's ok not to have found */
}
-/* Add package NAME to the list of packages encountered so far. To
- speed up class lookup in do_resolve_class, we make sure a
- particular package is added only once. */
-
-static void
-register_package (tree name)
-{
- static htab_t pht;
- void **e;
-
- if (pht == NULL)
- pht = htab_create (50, htab_hash_pointer, htab_eq_pointer, NULL);
-
- e = htab_find_slot (pht, name, INSERT);
- if (*e == NULL)
- {
- package_list = chainon (package_list, build_tree_list (name, NULL));
- *e = name;
- }
-}
-
static tree
resolve_package (tree pkg, tree *next, tree *type_name)
{