This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Patch: verifier fixes for gcj


Alex, here are my verifier "fixes" I promised you.  These changes work
around the build bugs we were seeing with the XML code.

The rationale behind these changes is that we should never indicate
that type unification can't happen when both types are reference
types, because we can always return `Object'.

I think this is probably a kludge, but sadly I don't even know enough
about verification to say that with any certainty.  I did find some
text in the JVM Spec to support this idea, and I found a very
interesting web page on this same topic (concerning an oversight in
the spec for invokevirtual) which I could probably dig up again if you
want to read it.

I think a better fix would be for us to write a different, smarter,
verifier, preferably one that could be integrated into libgcj as well.
Obviously that wasn't in the cards given my schedule though.

Even if this patch is the right approach, it is still a kludge because
it just reverts to using Object even if the two types in question have
a common superinterface.  It would be nicer to check for that.

So, I submit this not with the intent of committing it (though I
certainly will if that is what you think is best) but instead to
provoke commentary...


2000-08-31  Tom Tromey  <tromey@cygnus.com>

	* expr.c (pop_type_0): Return `Object' if trying to merge two
	interface types.

	* verify.c (merge_types): Don't return `TYPE_UNKNOWN' for
	interface types; `Object' is always a valid supertype.

Tom

Index: java/expr.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/expr.c,v
retrieving revision 1.83
diff -u -r1.83 expr.c
--- expr.c	2000/08/29 16:43:31	1.83
+++ expr.c	2000/09/03 22:02:26
@@ -320,9 +320,8 @@
       /* This is a kludge, but matches what Sun's verifier does.
 	 It can be tricked, but is safe as long as type errors
 	 (i.e. interface method calls) are caught at run-time. */
-      else if (CLASS_INTERFACE (TYPE_NAME (TREE_TYPE (type)))
-	       && t == object_ptr_type_node)
-	return t;
+      /* FIXME: this is worse than a kludge, probably.  */
+      return object_ptr_type_node;
     }
   return NULL_TREE;
 }
Index: java/verify.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/verify.c,v
retrieving revision 1.31
diff -u -r1.31 verify.c
--- verify.c	2000/08/16 00:05:29	1.31
+++ verify.c	2000/09/03 22:02:40
@@ -159,6 +173,8 @@
 
       if (CLASS_INTERFACE (TYPE_NAME (tt1)))
 	{
+	  /* FIXME: should see if two interfaces have a common
+	     superinterface.  */
 	  if (CLASS_INTERFACE (TYPE_NAME (tt2)))
 	    {
 	      /* This is a kludge, but matches what Sun's verifier does.
@@ -171,7 +187,7 @@
 	      if (can_widen_reference_to (tt2, tt1))
 		return type1;
 	      else
-		return TYPE_UNKNOWN;
+		return object_ptr_type_node;
 	    }
 	}
       else if (CLASS_INTERFACE (TYPE_NAME (tt2)))
@@ -179,7 +195,7 @@
 	  if (can_widen_reference_to (tt1, tt2))
 	    return type2;
 	  else
-	    return TYPE_UNKNOWN;
+	    return object_ptr_type_node;
 	}
 
       type1 = tt1;

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]