[Bug java/26042] New: ICE in mark_reference_fields, at java/boehm.c:105

[Bug java/26042] New: ICE in mark_reference_fields, at java/boehm.c:105

[bje at gcc dot gnu dot org]

This source file, when compiled with gcj produces an ICE:

package x;

class One
{
    long l;    // no ICE if this is int, not long
    int b;     // no ICE if this line is gone; type doesn't matter
}

class Two
{
    class Three extends One { }
    Three three () { return new Three (); }
}

The assertion failure is due to:

          /* If this reference slot appears to overlay a slot we think
             we already covered, then we are doomed.  */
          if (offset <= *last_view_index)
            abort ();


-- 
           Summary: ICE in mark_reference_fields, at java/boehm.c:105
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bje at gcc dot gnu dot org
  GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042

[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-01-31 03:16 -------
Confirmed on powerpc-darwin also.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   GCC host triplet|powerpc-linux               |
 GCC target triplet|powerpc-linux               |powerpc-*
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|0000-00-00 00:00:00         |2006-01-31 03:16:33
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042

[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105

[tromey at gcc dot gnu dot org]

------- Comment #2 from tromey at gcc dot gnu dot org  2006-01-31 17:40 -------
Thanks for the concise report.

This abort occurs when computing a GC bitmap descriptor of a class.
What it means is that we think we've seen overlapping fields in the
class -- which is a "can't happen" in java.

It might help if you could run gdb on jc1 and see the values of
'offset' and '*last_view_index'.  Based on the test case and the
location of the abort I would say that, for some reason, the
implicit 'this$0' field in Three is somehow overlapping the fields
inherited from its superclass.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042

[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105

[bje at gcc dot gnu dot org]

------- Comment #3 from bje at gcc dot gnu dot org  2006-02-03 04:06 -------
(gdb) p offset
$1 = 16
(gdb) p *last_view_index
$2 = 16

(gdb) p field
$3 = 0xf7ef9850
(gdb) pt
 <field_decl 0xf7ef9850 this$0
    type <pointer_type 0xf7f37680
        type <record_type 0xf7f37618 Two tree_2 type_2 type_3 type_4 type_5 SI
            size <integer_cst 0xf7ee0500 constant invariant 32>
            unit size <integer_cst 0xf7ee0900 constant invariant 4>
            align 32 symtab 0 alias set -1 fields <field_decl 0xf7f3e070 D.593>
            pointer_to_this <pointer_type 0xf7f37680> chain <type_decl
0xf7efa300 Two>>
        unsigned SI size <integer_cst 0xf7ee0500 32>
        unit size <integer_cst 0xf7ee0280 constant invariant 4>
        align 32 symtab 0 alias set -1>
    private unsigned decl_7 SI file Both.java line 9 size <integer_cst
0xf7ee0500 32> unit size <int\
eger_cst 0xf7ee0280 4>
    align 32 offset_align 128
    offset <integer_cst 0xf7ee0d80 type <integer_type 0xf7ee6138> constant
invariant 16>
    bit offset <integer_cst 0xf7ee07e0 type <integer_type 0xf7ee61a0
bit_size_type> constant invaria\
nt 0> context <record_type 0xf7f376e8 Two$Three>>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042

[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105

[tromey at gcc dot gnu dot org]

------- Comment #4 from tromey at gcc dot gnu dot org  2006-02-04 02:29 -------
Quick update... we debugged this a bit and found that
the field decl representing Three's superclass (the one made
by push_super_field) claims to have size 16 -- and yet
the 'b' field claims to have offset 16.  So, something seems
to be going wrong with type layout in this case.

Also, a similar C program yields the expected results.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042

[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2006-03-20 09:09 -------
I wonder why this seems to be ppc specific.  powerpc64 works, as does i686. 
3.3.3 also fails, so probably not a regression.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.1.0 4.2.0 3.3.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042

[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105

[bje at gcc dot gnu dot org]

------- Comment #6 from bje at gcc dot gnu dot org  2006-03-21 02:54 -------
Based on an investigation of the problem by myself and Tom, it appears to be
due to the object layout chosen for PPC32 (and presumably other) targets.


-- 

bje at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janis187 at us dot ibm dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042

[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105

[tromey at gcc dot gnu dot org]

------- Comment #7 from tromey at gcc dot gnu dot org  2006-03-27 22:03 -------
I was able to reproduce this with svn head on a ppc32 build.
A ppc64 build did not show this bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042

[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105

[tromey at gcc dot gnu dot org]

------- Comment #8 from tromey at gcc dot gnu dot org  2006-03-28 01:14 -------
One curiosity I noticed while debugging is that in layout_type,
class Two has size 128 (in bits).  This value is incorrect.
Once we reach the code to compute the GC descriptor, the
size is 192.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042

[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105

[tromey at gcc dot gnu dot org]

------- Comment #9 from tromey at gcc dot gnu dot org  2006-03-29 15:12 -------
The first time we lay out the type, we have the fields reversed.
See parse.y:java_reorder_fields.  I don't know why this happens.
(We construct the field list in reverse order, presumably for
efficiency.  What is unclear is why the type can be laid out
before the fields are correctly ordered.)

In any case, on ppc32, the ordering of fields matters, because
the class One can be packed more efficiently if 'b' comes first.

Then what happens is that when we lay out Two$Three, the initial
size of One is used to lay out the super class field.  This field's
size is not recomputed the second time we lay out Two$Three, yielding
the incorrect result.

One possible fix would be to reset the field sizes when we null out
TYPE_SIZE in java_reorder_fields (and perhaps elsewhere).

A better fix might be to remove the need for reordering fields.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042

[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105

[tromey at gcc dot gnu dot org]

-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |tromey at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-01-31 03:16:33         |2006-03-29 16:52:00
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042

[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105

[tromey at gcc dot gnu dot org]

------- Comment #10 from tromey at gcc dot gnu dot org  2006-03-30 16:39 -------
Subject: Bug 26042

Author: tromey
Date: Thu Mar 30 16:39:17 2006
New Revision: 112540

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112540
Log:
gcc/java
        PR java/26042:
        * parse.y (java_reorder_fields): Reset superclass field's size as
        well.
libjava
        PR java/26042:
        * testsuite/libjava.compile/pr26042.java: New file.

Added:
    trunk/libjava/testsuite/libjava.compile/pr26042.java
Modified:
    trunk/gcc/java/ChangeLog
    trunk/gcc/java/parse.y
    trunk/libjava/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042

[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105

[tromey at gcc dot gnu dot org]

------- Comment #11 from tromey at gcc dot gnu dot org  2006-03-30 16:47 -------
Subject: Bug 26042

Author: tromey
Date: Thu Mar 30 16:47:23 2006
New Revision: 112541

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112541
Log:
gcc/java
        PR java/26042:
        * parse.y (java_reorder_fields): Reset superclass field's size as
        well.
libjava
        PR java/26042:
        * testsuite/libjava.compile/pr26042.java: New file.

Added:
    branches/gcc-4_1-branch/libjava/testsuite/libjava.compile/pr26042.java
      - copied unchanged from r112540,
trunk/libjava/testsuite/libjava.compile/pr26042.java
Modified:
    branches/gcc-4_1-branch/gcc/java/ChangeLog
    branches/gcc-4_1-branch/gcc/java/parse.y
    branches/gcc-4_1-branch/libjava/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042

[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105

[tromey at gcc dot gnu dot org]

------- Comment #12 from tromey at gcc dot gnu dot org  2006-03-30 16:49 -------
I checked the fix into the 4.1 branch and the trunk.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.1.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042