This is the mail archive of the
java-prs@sourceware.cygnus.com
mailing list for the Java project.
Re: gcj/131
- To: apbianco at cygnus dot com
- Subject: Re: gcj/131
- From: Alexandre Petit-Bianco <apbianco at cygnus dot com>
- Date: 29 Mar 2000 03:16:00 -0000
- Cc: java-prs at sourceware dot cygnus dot com,
- Reply-To: Alexandre Petit-Bianco <apbianco at cygnus dot com>
The following reply was made to PR gcj/131; it has been noted by GNATS.
From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: java-gnats@sourceware.cygnus.com
Cc:
Subject: Re: gcj/131
Date: Tue, 28 Mar 2000 19:14:05 -0800 (PST)
Pekka Nikander writes:
> Integer constants etc are handled before; CONVERT_EXPR (which does have
> a TREE_TYPE defined) trips on this; e.g. PLUS_EXPR doesn't have a type
> defined, and it passes.
>
> Maybe this whole test is more or less bogus?
Yes, It looks like the whole test could go, especially since
{VAR,FIELD}_DECLs are properly handled in the switch statement down
below, I think this patch could be applied:
Index: parse.y
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/parse.y,v
retrieving revision 1.146
diff -u -p -r1.146 parse.y
--- parse.y 2000/03/23 07:01:24 1.146
+++ parse.y 2000/03/29 02:07:49
@@ -14488,8 +14503,6 @@ fold_constant_for_init (node, context)
if (code == INTEGER_CST || code == REAL_CST)
return convert (TREE_TYPE (context), node);
- if (TREE_TYPE (node) != NULL_TREE && code != VAR_DECL && code != FIELD_DECL)
- return NULL_TREE;
switch (code)
{
And with the new 1.1 enabled front end, gcj won't trip on the
following code:
class dummy {
static final byte b0 = 1;
static final byte b1 = (byte)2;
static final byte b2 = b0+b1;
}
And will have `b2' initialized to 2 without any intervention from
<clinit>. Then the next step is the prevent <clinit> from being
generated unless necessary -- I'm working on it.
./A