public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* java/1137: Static array length access bug in gcj
@ 2000-12-20 12:09 anandkr
  0 siblings, 0 replies; only message in thread
From: anandkr @ 2000-12-20 12:09 UTC (permalink / raw)
  To: java-gnats

>Number:         1137
>Category:       java
>Synopsis:       Static array length access bug in gcj
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apbianco
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 20 12:06:29 PST 2000
>Closed-Date:    Thu Jun 01 09:05:17 PDT 2000
>Last-Modified:  Thu Jun  1 09:16:00 PDT 2000
>Originator:     Anand Krishnaswamy
>Release:        gcc version 2.95.1 19990816 (release)
>Organization:
>Environment:
Reading specs from /opt/lib/gcc-lib/powerpc-unknown-linux-gnu/2.95.1/specs 
Reading specs from /opt/lib/libgcj.spec 
rename spec lib to liborig 

>Description:
I get a compiler error when I try the following. Any ideas? 
Anand 

:::::::::::::: 
A.java 
:::::::::::::: 
public class A { 
   public static String[] strArr = { "A", "B", "C" }; 
} 
:::::::::::::: 
B.java 
:::::::::::::: 
import java.lang.*; 
import java.util.*; 

public class B { 
   public static void main ( String[] args ) { 
        int length = A.strArr.length; 
        System.out.println ( "Array length: " + length ); 
   } 
} 

$ gcj --main=B A.java B.java 
B.java:6: Internal compiler error: 
B.java:6: Internal compiler error in `expand_expr', at expr.c:5750 
Please submit a full bug report. 
See <URL: < http://www.gnu.org/software/gcc/faq.html#bugreport >> for instructions. 

>How-To-Repeat:
See description
>Fix:

>Release-Note:

>Audit-Trail:

Formerly PR gcj/129

State-Changed-From-To: open->analyzed
State-Changed-By: green
State-Changed-When: Sun Mar  5 01:10:29 2000
State-Changed-Why:
    This is reproducable even in recent compilers and
    on IA-32 as well as PPC.  
    I've added test code to the libgcj testsuite for this.
    

From: green@sourceware.cygnus.com
To: java-gnats@sourceware.cygnus.com
Cc:  
Subject: gcj/129
Date: 5 Mar 2000 09:07:27 -0000

 CVSROOT:	/cvs/java
 Module name:	libgcj
 Changes by:	green@sourceware.cygnus.com	00/03/05 01:07:27
 
 Modified files:
 	libjava/testsuite: ChangeLog 
 Added files:
 	libjava/testsuite/libjava.compile: PR129_B.java 
 	libjava/testsuite/libjava.compile/support: PR129_A.java 
 
 Log message:
 	* libjava.compile/PR129_B.java: New file.
 	* libjava.compile/support/PR129_A.java: New file.
 	For PR gcj/129.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/gcc/libjava/testsuite/ChangeLog.diff?cvsroot=java&r1=1.57&r2=1.58
 http://gcc.gnu.org/cgi-bin/gcc/libjava/testsuite/libjava.compile/PR129_B.java.diff?cvsroot=java&r1=NONE&r2=1.1
 http://gcc.gnu.org/cgi-bin/gcc/libjava/testsuite/libjava.compile/support/PR129_A.java.diff?cvsroot=java&r1=NONE&r2=1.1
 

From: green@cygnus.com
To: anandkr@nortelnetworks.com, apbianco@cygnus.com,
  java-gnats@sourceware.cygnus.com
Cc:  
Subject: Re: gcj/129
Date: 5 Mar 2000 09:10:29 -0000

 Synopsis: Static array length access bug in gcj
 
 State-Changed-From-To: open->analyzed
 State-Changed-By: green
 State-Changed-When: Sun Mar  5 01:10:29 2000
 State-Changed-Why:
     This is reproducable even in recent compilers and
     on IA-32 as well as PPC.  
     I've added test code to the libgcj testsuite for this.
     
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=129&database=java

From: Tom Tromey <tromey@cygnus.com>
To: Java Gnats Server <java-gnats@sourceware.cygnus.com> 
Cc: Alexandre Petit-Bianco <apbianco@cygnus.com> 
Subject: gcj/129
Date: 28 Apr 2000 11:01:32 -0600

 I looked at PR gcj/129 a little bit today.
 The crash occurs in expand_expr when trying to expand the VAR_DECL for
 the array in the other class.
 
 I think this happens when we fail to call make_decl_rtl on a static
 field.  I believe this usually happens when build_field_ref is called
 from maybe_generate_pre_expand_clinit.
 
 However, in this case, we don't call that function for
 support.PR129_A.  I'm not sure why, but I assume it has something to
 do with the fact that we aren't compiling that class -- just reading
 it.
 
 Tom

From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: Java Gnats Server <java-gnats@sourceware.cygnus.com>
Cc:  
Subject: Re: gcj/129
Date: Fri, 28 Apr 2000 14:50:54 -0700 (PDT)

 Tom Tromey writes:
 
 > However, in this case, we don't call that function for
 > support.PR129_A.  I'm not sure why, but I assume it has something to
 > do with the fact that we aren't compiling that class -- just reading
 > it.
 
 Yes. I have the following patch, but the runtime fails because we're
 not initializing class `A' before we use `strArr'. This needs to be
 fixed.
 
 ./A
 
 Index: parse.y
 ===================================================================
 RCS file: /cvs/gcc/egcs/gcc/java/parse.y,v
 retrieving revision 1.157
 diff -u -p -r1.157 parse.y
 --- parse.y	2000/04/25 22:14:53	1.157
 +++ parse.y	2000/04/28 21:49:02
 @@ -4008,6 +4010,10 @@ lookup_field_wrapper (class, name)
  	FIELD_LOCAL_ALIAS_USED (decl) = 1;
      }
  
 +  if (decl && decl != error_mark_node
 +      && !DECL_RTL (decl) && FIELD_STATIC (decl) && type != current_class)
 +    build_field_ref (NULL_TREE, type, DECL_NAME (decl));
 +
    java_parser_context_restore_global ();
    return decl == error_mark_node ? NULL : decl;
  }

From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: Java Gnats Server <java-gnats@sourceware.cygnus.com>
Cc:  
Subject: Re: gcj/129
Date: Tue, 2 May 2000 00:10:47 -0700 (PDT)

 Alexandre Petit-Bianco writes:
 
 > Yes. I have the following patch, but the runtime fails because we're
 > not initializing class `A' before we use `strArr'. This needs to be
 > fixed.
 
 This patch wasn't really fixing the problem at its source. Here's an
 other one I think is better.
 
 ./A
 
 2000-05-02  Alexandre Petit-Bianco  <apbianco@kazmo.drew.net>
 
 	* parse.y (resolve_field_access): Call the appropriate <clinit>
 	before accessing the length of a static array. Craft a decl for
 	the field while its time.
  
 Index: parse.y
 ===================================================================
 RCS file: /cvs/gcc/egcs/gcc/java/parse.y,v
 retrieving revision 1.160
 diff -u -p -r1.160 parse.y
 --- parse.y	2000/05/01 22:32:20	1.160
 +++ parse.y	2000/05/02 07:04:13
 @@ -8576,6 +8636,18 @@ resolve_field_access (qual_wfl, field_de
        tree length = build_java_array_length_access (where_found);
        field_ref =
 	build_java_arraynull_check (type_found, length, int_type_node);
 +
 +      /* In case we're dealing with a static array, we need to
 +	 initialize its class before the array length can be fetched.
 +	 It's also a good time to create a DECL_RTL for the field if
 +	 none already exists, otherwise if the field was declared in a
 +	 class found in an external file and hasn't been (and won't
 +	 be) accessed for its value, none will be created. */
 +      if (TREE_CODE (where_found) == VAR_DECL && FIELD_STATIC (where_found))
 +	{
 +	  build_static_field_ref (where_found);
 +	  field_ref = build_class_init (DECL_CONTEXT (where_found), field_ref);
 +	}
      }
    /* We might have been trying to resolve field.method(). In which
       case, the resolution is over and decl is the answer */
 
 
 
State-Changed-From-To: analyzed->feedback
State-Changed-By: apbianco
State-Changed-When: Mon May  8 16:32:31 2000
State-Changed-Why:
    There is already a patch which seems to be descent.

From: apbianco@cygnus.com
To: anandkr@nortelnetworks.com, apbianco@cygnus.com,
  java-gnats@sourceware.cygnus.com
Cc:  
Subject: Re: gcj/129
Date: 8 May 2000 23:32:31 -0000

 Synopsis: Static array length access bug in gcj
 
 State-Changed-From-To: analyzed->feedback
 State-Changed-By: apbianco
 State-Changed-When: Mon May  8 16:32:31 2000
 State-Changed-Why:
     There is already a patch which seems to be descent.
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=129&database=java
State-Changed-From-To: feedback->closed
State-Changed-By: apbianco
State-Changed-When: Thu Jun  1 09:05:17 2000
State-Changed-Why:
    I checked in the following patch:
    
      http://gcc.gnu.org/ml/gcc-patches/2000-06/msg00015.html
    
      

From: apbianco@cygnus.com
To: anandkr@nortelnetworks.com, apbianco@cygnus.com,
  java-gnats@sourceware.cygnus.com
Cc:  
Subject: Re: gcj/129
Date: 1 Jun 2000 16:05:17 -0000

 Synopsis: Static array length access bug in gcj
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: apbianco
 State-Changed-When: Thu Jun  1 09:05:17 2000
 State-Changed-Why:
     I checked in the following patch:
     
       http://gcc.gnu.org/ml/gcc-patches/2000-06/msg00015.html
     
       
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=129&database=java
>Unformatted:



^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2000-12-20 12:09 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-12-20 12:09 java/1137: Static array length access bug in gcj anandkr

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).