This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
Re: Current libgcj tree warning
Tom Tromey writes:
> Ok, I did commit a compiler patch (actually two) which fix this
> problem. Alex, are there two different fixes for this floating
> around? Feel free to revert the one I checked in if the PR209 patch
> is the one you prefer now.
The `fold_constant_for_init' patch is a good one. But for final
constant in qualified expression, the patch for #209 should also be
used. Tom, rebuilding the entire tree would take too much time on my
old laptop (though I'm starting a build now.) As a result I wouldn't
be able to check in a rebuilt version of parse.c before hours. Can you
please check the following patch in? Thanks.
I'm closing PR #209.
./A
000-05-01 Alexandre Petit-Bianco <apbianco@cygnus.com
* parse.y (resolve_package): Correctly set `*next' (was off by
one.)
(resolve_qualified_expression_name): Fixed comment.
Index: parse.y
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/parse.y,v
retrieving revision 1.167
diff -u -p -r1.167 parse.y
--- parse.y 2000/05/19 22:04:08 1.167
+++ parse.y 2000/05/20 16:57:48
@@ -6679,7 +6679,10 @@ resolve_package (pkg, next)
if ((type_name = resolve_no_layout (acc, NULL_TREE)))
{
type_name = acc;
- *next = TREE_CHAIN (current);
+ /* resolve_package should be used in a loop, hence we
+ point at this one to naturally process the next one at
+ the next iteration. */
+ *next = current;
break;
}
}
@@ -8893,7 +8896,7 @@ resolve_qualified_expression_name (wfl,
{
tree list;
*where_found = decl = resolve_no_layout (name, qual_wfl);
- /* We wan't to be absolutely that the class is laid
+ /* We want to be absolutely sure that the class is laid
out. We're going to search something inside it. */
*type_found = type = TREE_TYPE (decl);
layout_class (type);