public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* java/1186: Compiler generates incorrect array initialization code
@ 2000-12-20 12:22 jsturm
0 siblings, 0 replies; only message in thread
From: jsturm @ 2000-12-20 12:22 UTC (permalink / raw)
To: java-gnats
>Number: 1186
>Category: java
>Synopsis: Compiler generates incorrect array initialization code
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: apbianco
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Dec 20 12:17:16 PST 2000
>Closed-Date: Tue Sep 05 20:27:13 PDT 2000
>Last-Modified: Tue Sep 5 20:30:00 PDT 2000
>Originator: Jeff Sturm
>Release: CVS
>Organization:
>Environment:
alphapca56-unknown-linux-gnu
>Description:
The attached class prints the wrong output when compiled
from Java source to native code. The code that
initializes the int array seems to be shifted by four
octets.
Compiling first to bytecode and then native does not exhibit
the problem.
(Is there any good reason static arrays are initialized
at runtime instead of generating an initialized data
object?)
>How-To-Repeat:
[jsturm@cc42593-a tmp]$ gcj StaticArray.java --main=StaticArray -o staticarray
[jsturm@cc42593-a tmp]$ ./staticarray
2
3
4
0
(Expected output is 1,2,3,4)
>Fix:
>Release-Note:
>Audit-Trail:
Formerly PR gcj/214
From: Tom Tromey <tromey@cygnus.com>
To: jsturm@sigma6.com
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: gcj/214: Compiler generates incorrect array initialization code
Date: Sat, 22 Apr 2000 14:46:55 -0700 (PDT)
Jeff> (Is there any good reason static arrays are initialized at
Jeff> runtime instead of generating an initialized data object?)
Nobody has done the work.
Other than that, no -- it is a good idea.
Tom
From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: java-gnats@sourceware.cygnus.com
Cc:
Subject: Re: gcj/214: Compiler generates incorrect array initialization code
Date: Sat, 22 Apr 2000 16:12:47 -0700 (PDT)
jsturm@sigma6.com writes:
> [jsturm@cc42593-a tmp]$ ./staticarray
> 2
> 3
> 4
> 0
>
> (Expected output is 1,2,3,4)
> >Fix:
Jeff, please try the following patch:
2000-04-05 Alexandre Petit-Bianco <apbianco@cygnus.com>
* class.c (build_java_array_type): `data' to always use pointer
alignment.
Index: typeck.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/java/typeck.c,v
retrieving revision 1.51
diff -u -p -r1.51 typeck.c
--- typeck.c 2000/03/13 19:42:33 1.51
+++ typeck.c 2000/04/06 01:44:57
@@ -417,6 +417,7 @@ build_java_array_type (element_type, len
{
tree atype = build_prim_array_type (element_type, length);
tree arfld = build_decl (FIELD_DECL, get_identifier ("data"), atype);
+ TYPE_ALIGN (atype) = TYPE_ALIGN (ptr_type_node);
DECL_CONTEXT (arfld) = t;
TREE_CHAIN (fld) = arfld;
./A
From: Tom Tromey <tromey@cygnus.com>
To: Alexandre Petit-Bianco <apbianco@cygnus.com>
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: gcj/214: Compiler generates incorrect array initialization code
Date: Sat, 22 Apr 2000 18:12:46 -0700 (PDT)
Alex> * class.c (build_java_array_type): `data' to always use pointer
Alex> alignment.
Hi Alex.
Two questions about this patch:
1. Don't we need a corresponding runtime patch?
2. Is pointer alignment sufficient? On x86 I think doubles have
stricter alignment than pointers.
Tom
From: Jeff Sturm <jsturm@sigma6.com>
To: java-gnats@sourceware.cygnus.com, jsturm@sigma6.com, apbianco@cygnus.com
Cc:
Subject: Re: gcj/214
Date: Mon, 24 Apr 2000 01:44:45 -0400
Alex's patch works for me, thanks. I haven't tested on ia32 though.
(Next time Alex can you Cc: me, since I don't subscribe to java-gnats?)
The runtime should be OK now, since it doesn't make any assumptions
about aligment of array members, right?
http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=214&database=java
--
Jeff Sturm
jsturm@sigma6.com
From: Jeff Sturm <jsturm@sigma6.com>
To: java-gnats@sourceware.cygnus.com, tromey@cygnus.com, apbianco@cygnus.com
Cc:
Subject: Re: gcj/214
Date: Mon, 24 Apr 2000 11:49:15 -0400
Tom Tromey wrote:
> 2. Is pointer alignment sufficient? On x86 I think doubles have
> stricter alignment than pointers.
Good question. It turns out that double arrays are broken on x86, both
with and without this patch.
Take the test case above, replace `int' with `double' and try it.
You want me to submit a new bug?
--
Jeff Sturm
jsturm@sigma6.com
From: Tom Tromey <tromey@cygnus.com>
To: Jeff Sturm <jsturm@sigma6.com>
Cc: apbianco@cygnus.com, java-gnats@sourceware.cygnus.com
Subject: Re: gcj/214
Date: Mon, 24 Apr 2000 10:03:06 -0700 (PDT)
Jeff> You want me to submit a new bug?
No -- we're aware of this and we'll probably solve it soon.
T
From: Jeff Sturm <jsturm@sigma6.com>
To: tromey@cygnus.com
Cc: java-gnats@sourceware.cygnus.com, apbianco@cygnus.com
Subject: Re: gcj/214
Date: Sun, 04 Jun 2000 11:02:24 -0400
> Jeff> You want me to submit a new bug?
>
> No -- we're aware of this and we'll probably solve it soon.
This never did get resolved. I filed PR/252 for the case of double
arrays.
--
Jeff Sturm
jeff.sturm@appnet.com
From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: java-gnats@sourceware.cygnus.com
Cc:
Subject: Re: gcj/214
Date: Sun, 4 Jun 2000 10:14:56 -0700 (PDT)
Jeff Sturm writes:
> > Jeff> You want me to submit a new bug?
> >
> > No -- we're aware of this and we'll probably solve it soon.
>
> This never did get resolved. I filed PR/252 for the case of double
> arrays.
It's been on my TODO list for a while now. Thanks for the PR, I'll
look into this annoying bug ASAP.
./A
State-Changed-From-To: open->closed
State-Changed-By: apbianco
State-Changed-When: Tue Sep 5 20:27:13 2000
State-Changed-Why:
I checked in Andrew Haley's patch:
http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00907.html
From: apbianco@cygnus.com
To: apbianco@cygnus.com, java-gnats@sourceware.cygnus.com, jsturm@sigma6.com
Cc:
Subject: Re: gcj/214
Date: 6 Sep 2000 03:27:13 -0000
Synopsis: Compiler generates incorrect array initialization code
State-Changed-From-To: open->closed
State-Changed-By: apbianco
State-Changed-When: Tue Sep 5 20:27:13 2000
State-Changed-Why:
I checked in Andrew Haley's patch:
http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00907.html
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=214&database=java
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="StaticArray.java"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="StaticArray.java"
cHVibGljIGNsYXNzIFN0YXRpY0FycmF5IHsKICAgIHN0YXRpYyBpbnQgdGFibGVbXSA9IHsxLCAy
LCAzLCA0fTsKCiAgICBwdWJsaWMgc3RhdGljIHZvaWQgbWFpbihTdHJpbmdbXSBhcmdzKSB7CiAg
ICAgICAgZm9yIChpbnQgbiA9IDA7IG4gPCB0YWJsZS5sZW5ndGg7IG4rKykKICAgICAgICAgICAg
U3lzdGVtLm91dC5wcmludGxuKChpbnQpdGFibGVbbl0pOwogICAgfQp9Cg==
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2000-12-20 12:22 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:22 java/1186: Compiler generates incorrect array initialization code jsturm
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).