libgcj/5783: verify.cc compatibility fails check on local variable

libgcj/5783: verify.cc compatibility fails check on local variable

[toddastock]

>Number:         5783
>Category:       libgcj
>Synopsis:       verify.cc compatibility fails check on local variable
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 25 21:46:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        3.1 20020225 (experimental)
>Organization:
>Environment:
System: Linux escher 2.4.9-21 #1 Thu Jan 17 14:16:30 EST 2002 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ./configure --enable-threads=posix --prefix=/home/tstock/local --disable-shared --enable-languages=c++,java : (reconfigured)  : (reconfigured) 
>Description:
This may be a problem in the merge code merging incorrectly to unsuitable_type.
>How-To-Repeat:
import java.io.*;
import java.util.*;
import java.lang.reflect.*;

public class Test
  {

  public static void main (String[] args)
    {

      Test t = new Test( );
      try
        {
          t.doit( "" );
        }
      catch( ClassNotFoundException e )
        {
        }
    }

  Vector pathComponents  = new Vector();

    private String getClassFilename(String classname) {
        return classname.replace('.', '/') + ".class";
    }

    private InputStream getResourceStream(File file, String resourceName) {
      return null;
    }

    private Class getClassFromStream(InputStream stream, String classname)
                throws IOException {
      return null;
    }

    private Class doit(String name) throws ClassNotFoundException {
        InputStream stream = null;
        String classFilename = getClassFilename(name);
        try {
            for (Enumeration e = pathComponents.elements(); e.hasMoreElements(); ) {
                File pathComponent = (File)e.nextElement();
                try {
                    stream = getResourceStream(pathComponent, classFilename);
                    if (stream != null) {
                        return getClassFromStream(stream, name);
                    }
                }
                catch (IOException ioe) {
                    // ioe.printStackTrace();
//                    log("Exception reading component " + pathComponent , Project.MSG_VERBOSE);
                }
            }
            
            throw new ClassNotFoundException(name);
        }
        finally {
            try {
                if (stream != null) {
                    stream.close();
                }
            }
            catch (IOException e) {}
        }
    }
  }
>Fix:
Index: verify.cc
===================================================================
RCS file: /cvsroot/gcc/gcc/libjava/verify.cc,v
retrieving revision 1.39
diff -u -r1.39 verify.cc
--- verify.cc	20 Feb 2002 03:16:30 -0000	1.39
+++ verify.cc	26 Feb 2002 05:40:09 -0000
@@ -460,6 +460,8 @@
       // Any type is compatible with the unsuitable type.
       if (key == unsuitable_type)
 	return true;
+      if (k.key == unsuitable_type)
+	return true;
 
       if (key < reference_type || k.key < reference_type)
 	return key == k.key;
>Release-Note:
>Audit-Trail:
>Unformatted:

Re: libgcj/5783: verify.cc compatibility fails check on local variable

[Tom Tromey]

The following reply was made to PR libgcj/5783; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: toddastock@yahoo.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libgcj/5783: verify.cc compatibility fails check on local variable
Date: 26 Feb 2002 11:32:23 -0700

 >>>>> "Todd" == Todd Stock <toddastock@yahoo.com> writes:
 
 Todd> Number:         5783
 Todd> Synopsis:       verify.cc compatibility fails check on local variable
 
 Todd> This may be a problem in the merge code merging incorrectly to
 Todd> unsuitable_type.
 
 I tried this.
 
 If I compile with `gcj -C' then all of gij, gcj --syntax-only, and
 java (Sun JDK 1.2) agree that the bytecode is invalid.
 
 If I compile with `javac' then they all agree it is correct.
 
 So I think we're seeing a compiler bug here, and not a verifier bug.
 
 Tom