java/4158: ICE in generate_bytecode_conditional(); SP mismatch

java/4158: ICE in generate_bytecode_conditional(); SP mismatch

[david-b]

>Number:         4158
>Category:       java
>Synopsis:       ICE in generate_bytecode_conditional(); SP mismatch
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          ice-on-legal-code
>Submitter-Id:   net
>Arrival-Date:   Tue Aug 28 12:46:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     david-b@pacbell.net
>Release:        gcj 3.0
>Organization:
>Environment:
Linux 2.4.7 kernel, RedHat 7.0
i686-pc-linux-gnu
gcj configured --enable-threads=posix --enable-languages=c++,java --enable-checking
>Description:
        ICE reported:
          gcj -femit-class-files -Isource -foutput-class-dir=bin ...
./source/gnu/xml/dom/JAXPFactory.java: In class `':
./source/gnu/xml/dom/JAXPFactory.java: In method `(org.xml.sax.XMLReader,gnu.xml.dom.JAXPFactory)':
./source/gnu/xml/dom/JAXPFactory.java:162: Internal compiler error in generate_bytecode_conditional, at java/jcf-write.c:1350
Please submit a full bug report,
with preprocessed source if appropriate.
        This particular line of code is the "if":
            // if validating, default to treating validity errors as fatal
            if (factory.isValidating ())
                producer.setErrorHandler (this);
        This is a static final inner class.
        "factory" an instance of the enclosing (public final) class.
        "isValidating" is inherited from its (abstract) superclass.

Notice:  (a) ICE, (b) bogus diagnostic for classname

The ICE is essentially for an assertion
that state->code_SP didn't change (presumably,
while compiling that "if").
>How-To-Repeat:
        Get a current copy, from CVS, of the GNU JAXP project.
        That's CVS from http://savannah.gnu.org/software/classpathx ,
        the "jaxp" module. (The file in question is version
        1.3 in my version, dated 2001/6/24)

        Configure; change the JAVAC line in Makefile to 
JAVAC = gcj -femit-class-files -Isource -foutput-class-dir=$(CC-DESTDIR)
        Make.  See the ICE.
>Fix:
none known.  It may be that more current
versions of GCJ don't have this ICE.
>Release-Note:
>Audit-Trail:
>Unformatted:

Re: java/4158: ICE in generate_bytecode_conditional(); SP mismatch

[rodrigc]

Synopsis: ICE in generate_bytecode_conditional(); SP mismatch

State-Changed-From-To: feedback->closed
State-Changed-By: rodrigc
State-Changed-When: Sun Jan 27 15:56:56 2002
State-Changed-Why:
    No feedback.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4158

Re: java/4158: ICE in generate_bytecode_conditional(); SP mismatch

[David Brownell]

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

From: David Brownell <david-b@pacbell.net>
To: apbianco@cygnus.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/4158: ICE in generate_bytecode_conditional(); SP mismatch
Date: Sat, 22 Sep 2001 11:17:05 -0700

 No change.  Perhaps it's related to "Context" being an inner class?
 I know compiling inner classes needed fixes in the 3.1 tree.
 
 By the way, that was compiling with a file-at-a-time shell script.
 If I just use the Makefile there (after enabling GCJ and adding
 the -fsyntax-only flag) there is a segfault during compilation:
 
   mkdir -p bin
   if [ -e filelist.mak ] ; then \
     gcj -fsyntax-only -femit-class-files -Isource -foutput-class-dir=bin @filelist.mak  ; \
     rm filelist.mak ; \
   fi
   ./source/gnu/xml/dom/Consumer.java:0: Internal error: Segmentation fault
   Please submit a full bug report,
   with preprocessed source if appropriate.
   See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
 
 That file compiled when not using the @filelist.mak invocation, though
 I had to make the shell script "mkdir -p bin/gnu/xml/dom" first.
 
 - Dave
 
 
 ----- Original Message ----- 
 From: "Alexandre Petit-Bianco" <apbianco@cygnus.com>
 To: "David Brownell" <david-b@pacbell.net>
 Cc: <gcc-gnats@gcc.gnu.org>
 Sent: Saturday, September 22, 2001 10:35 AM
 Subject: Re: java/4158: ICE in generate_bytecode_conditional(); SP mismatch
 
 
 > 
 > David Brownell writes:
 > 
 > > However, I also got this when I ran a command ... at least
 > > some of the code being generated doesn't verify using
 > > Sun's JDK 1.3.0. 
 > 
 > Interesting. Could you try modifying NamespaceSupport.java like so and
 > give it an other try?
 > 
 > Thank you.
 > 
 > ./A
 > 
 > --- NamespaceSupport.java~ Fri Jul 14 17:30:44 2000
 > +++ NamespaceSupport.java Sat Sep 22 10:34:06 2001
 > @@ -118,7 +118,8 @@ public class NamespaceSupport
 >      {
 > contexts = new Context[32];
 > contextPos = 0;
 > - contexts[contextPos] = currentContext = new Context();
 > + currentContext = new Context();
 > + contexts[contextPos] = currentContext
 > currentContext.declarePrefix("xml", XMLNS);
 >      }
 > 
 

Re: java/4158: ICE in generate_bytecode_conditional(); SP mismatch

[Alexandre Petit-Bianco]

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

From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: David Brownell <david-b@pacbell.net>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/4158: ICE in generate_bytecode_conditional(); SP mismatch
Date: Sat, 22 Sep 2001 10:35:25 -0700 (PDT)

 David Brownell writes:
 
 > However, I also got this when I ran a command ... at least
 > some of the code being generated doesn't verify using
 > Sun's JDK 1.3.0. 
 
 Interesting. Could you try modifying NamespaceSupport.java like so and
 give it an other try?
 
 Thank you.
 
 ./A
 
 --- NamespaceSupport.java~	Fri Jul 14 17:30:44 2000
 +++ NamespaceSupport.java	Sat Sep 22 10:34:06 2001
 @@ -118,7 +118,8 @@ public class NamespaceSupport
      {
 	contexts = new Context[32];
 	contextPos = 0;
 -	contexts[contextPos] = currentContext = new Context();
 +	currentContext = new Context();
 +	contexts[contextPos] = currentContext
 	currentContext.declarePrefix("xml", XMLNS);
      }
  

Re: java/4158: ICE in generate_bytecode_conditional(); SP mismatch

[apbianco]

Synopsis: ICE in generate_bytecode_conditional(); SP mismatch

Responsible-Changed-From-To: unassigned->apbianco
Responsible-Changed-By: apbianco
Responsible-Changed-When: Fri Sep  7 09:47:38 2001
Responsible-Changed-Why:
    Mine
State-Changed-From-To: open->feedback
State-Changed-By: apbianco
State-Changed-When: Fri Sep  7 09:47:38 2001
State-Changed-Why:
    I can't reproduce this problem with a current version of
    gcj, all 230 files are building to native and bytecode (and
    I verified that the offending file is still in v1.3.)
    
    It is to be noted that a fair amount of bytecode backend work has been accomplished ever since 3.0 was frozen.
    
    Give 3.1 a try and let use know how it works for you.

http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=4158&database=gcc