[Bug libgcj/57074] New: gcc-4.8.0 libgcj regression on 32bit Power architecture

[Bug libgcj/57074] New: gcc-4.8.0 libgcj regression on 32bit Power architecture

[rsa at us dot ibm.com]

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

             Bug #: 57074
           Summary: gcc-4.8.0 libgcj regression on 32bit Power
                    architecture
    Classification: Unclassified
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: libgcj
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rsa@us.ibm.com


GCC Revision 186687 has been identified as causing a regression in PowerC
32-bit libgcj:

http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=186687

I've verified that this fails with upstream GCC:

ryanarn@bns:~> /home/bergner/gcc/install/gcc-fsf-4_8-java32/bin//gkeytool
-import -alias `basename 99.pem .pem` -keystore cacerts -storepass '' -file
99.pem
Exception in thread "main" java.lang.NoClassDefFoundError:
gnu.classpath.tools.keytool.Main
   at java.lang.Class.initializeClass(libgcj.so.14)
Caused by: java.lang.IllegalMonitorStateException: current thread not owner
   at java.lang.Object.notifyAll(libgcj.so.14)
   at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.14)
   at java.lang.ClassLoader.loadClass(libgcj.so.14)
   at java.lang.ClassLoader.loadClass(libgcj.so.14)
   at java.lang.Class.initializeClass(libgcj.so.14)

If this wasn't failing it would be reporting:

ryanarn@bns:~> ryanarn@bns:~>
/home/bergner/gcc/install/gcc-fsf-4_8-java/bin/gkeytool -import -alias
`basename 99.pem .pem` -keystore cacerts -storepass '' -file 99.pem
keytool error: java.security.InvalidParameterException: File object [99.pem]
MUST be an existing readable file
/home/bergner/gcc/install/gcc-fsf-4_8-java/bin/gkeytool -import -alias
`basename 99.pem .pem` -keystore cacerts -storepass '' -file 99.pem
keytool error: java.security.InvalidParameterException: File object [99.pem]
MUST be an existing readable file

I'm able to trap on the catch, but trying to capture the throw or identify the
state of the GCJ locking mechanisms when the problem happens has proven
problematic.  Turning on logging and lock debugging might help, but there's a
lot going on in the state initialization.  Here's a back trace:

Breakpoint 8, _Jv_Linker::wait_for_state (klass=klass@entry=0x10020018
<gnu::classpath::tools::keytool::Main::class$>, 
    state=state@entry=9) at ../../../libjava/link.cc:2086
2086        throw exc;
$8 = "In the wait_for_state catch."
klass: 0x10020018
(gdb) bt
#0  _Jv_Linker::wait_for_state (klass=klass@entry=0x10020018
<gnu::classpath::tools::keytool::Main::class$>, state=state@entry=9)
    at ../../../libjava/link.cc:2086
#1  0x0e2c2aec in java::lang::Class::initializeClass (this=0x10020018
<gnu::classpath::tools::keytool::Main::class$>)
    at ../../../libjava/java/lang/natClass.cc:728
#2  0x0e2c39b4 in _Jv_InitClass (klass=<optimized out>) at
../../../libjava/java/lang/Class.h:742
#3  0x0fe3eabc in gnu.classpath.tools.keytool.Main.main(java.lang.String[])void
(args=@f7d4ad50)
    at
../../../../../libjava/classpath/tools/gnu/classpath/tools/keytool/Main.java:137
#4  0x0e2b63c0 in gnu::java::lang::MainThread::call_main
(this=this@entry=0xf7ce7f60)
    at ../../../libjava/gnu/java/lang/natMainThread.cc:54
#5  0x0e33f3dc in gnu.java.lang.MainThread.run()void (this=@f7ce7f60)
    at
/usr/src/debug/gcc-4.8.0-20130412/libjava/gnu/java/lang/MainThread.java:106
#6  0x0e2cce88 in _Jv_ThreadRun (thread=0xf7ce7f60) at
../../../libjava/java/lang/natThread.cc:335
#7  0x0e26e6fc in _Jv_RunMain (vm_args=vm_args@entry=0x0, klass=<optimized
out>, name=name@entry=0x0, argc=<optimized out>, 
    argv=<optimized out>, is_jar=<optimized out>) at
../../../libjava/prims.cc:1790
#8  0x0e26e944 in _Jv_RunMain (klass=<optimized out>, name=name@entry=0x0,
argc=<optimized out>, argv=<optimized out>, 
    is_jar=is_jar@entry=false) at ../../../libjava/prims.cc:1815
#9  0x0e26e9a0 in JvRunMain (klass=<optimized out>, argc=<optimized out>,
argv=<optimized out>) at ../../../libjava/prims.cc:1821
#10 0x0d1c17f4 in generic_start_main (main=0x100004c0 <main>, argc=10,
ubp_av=0xfffef6f4, auxvec=0xfffef774, init=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=<optimized out>, fini=<optimized out>)
at ../csu/libc-start.c:258
#11 0x0d1c1990 in __libc_start_main (argc=<optimized out>, ubp_av=<optimized
out>, ubp_ev=<optimized out>, auxvec=<optimized out>, 
    rtld_fini=<optimized out>, stinfo=<optimized out>,
stack_on_entry=<optimized out>)
    at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:91
#12 0x00000000 in ?? ()

[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

[dje at gcc dot gnu.org]

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

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-04-30
                 CC|                            |dje at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #1 from David Edelsohn <dje at gcc dot gnu.org> 2013-04-30 20:45:54 UTC ---
Confirmed.

[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

[amodra at gmail dot com]

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

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gmail dot com

--- Comment #2 from Alan Modra <amodra at gmail dot com> 2013-05-02 08:18:45 UTC ---
BTW, running gkeytool without any args shows the problem too. When libjava is
built with -g -O2, I get

Exception in thread "main" java.lang.NoClassDefFoundError:
gnu.classpath.tools.keytool.Main
   at java.lang.Class.initializeClass(natClass.cc)
Caused by: java.lang.IllegalMonitorStateException: current thread not owner
   at java.lang.Object.notifyAll(natObject.cc:1437)
   at gnu.gcj.runtime.SystemClassLoader.findClass(natSystemClassLoader.cc:29)
   at java.lang.ClassLoader.loadClass(ClassLoader.java)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:387)
   at java.lang.Class.initializeClass(natClass.cc:728)

But note that natObject.cc:1437 is a lie!  The real failure occurs
natObject.cc:1431 and it looks like the two identical throws have merged. 
Putting a break on the right place, I see

(gdb) p this
$8 = (java::lang::Object * const) 0xffc6aec
<gnu::classpath::tools::keytool::Main$ShutdownHook::class$>
(gdb) p/x addr
$9 = 0xffc6aec

Uh oh!  The address is not 8-byte aligned, so one of the flag bits appears to
be set.  This is why we appear to have locking problems.

[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

[amodra at gmail dot com]

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

--- Comment #3 from Alan Modra <amodra at gmail dot com> 2013-05-02 08:54:39 UTC ---
In libgcj-tools.so
 20316: 00456aec   144 OBJECT  LOCAL  DEFAULT   22
_ZN3gnu9classpath5tools7keytool17Main$ShutdownHook6class$E

That's in .data, as expected.


>From the .o file (classpath/tools/.libs/libgcj_tools_la-tools.o) I see this is
laid out *not* at an 8 byte address.

26803: 000680ac   144 OBJECT  GLOBAL HIDDEN   110
_ZN3gnu9classpath5tools7keytool17Main$ShutdownHook6class$E

While the containing section is 8-byte aligned.
  [110] .data.rel.local   PROGBITS        00000000 2151b8 07358c 00  WA  0   0 
8


So a gcj bug by the look of it.

[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

[amodra at gmail dot com]

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

--- Comment #4 from Alan Modra <amodra at gmail dot com> 2013-05-02 11:35:20 UTC ---
I believe this is triggered by powerpc turning on -fsection-anchors by default,
and a section anchor bug loses the alignment.  The classes are all nicely
aligned if I compile with -fno-section-anchors

[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

[amodra at gmail dot com]

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

--- Comment #5 from Alan Modra <amodra at gmail dot com> 2013-05-02 14:01:59 UTC ---
So the section anchor code places vars (and constants) in blocks according to
their alignment and sizes (varasm.c:place_block_symbol).  The calculations are
all good, offsets are properly aligned, and the overall block aligned.  The
problem is that when we come to actually output the vars, in some cases we emit
*more* data than given by the size.  That results in following vars being at a
different offset than originally calculated, and sometimes misaligned.

Here's an example of output showing the mismatch.
        .type   _atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook,
@object
        .size   _atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook, 24
_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook:
        .long   _Utf259
        .long   _Utf111
        .long   _Utf110
        .long   _Utf166
        .long   _Utf111
        .long   _Utf257
        .long   0
        .long   0
        .long   0
Notice the actual size is 36 bytes, not the 24 give by .size.

 <var_decl 0xfffb621be98
_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook
    type <array_type 0xfffb60f4788
        type <record_type 0xfffb60f46e0 BLK
            size <integer_cst 0xfffb5ff2aa0 constant 96>
            unit size <integer_cst 0xfffb5ff2ae0 constant 12>
            align 32 symtab 0 alias set 22 canonical type 0xfffb60f46e0 fields
<field_decl 0xfffb6020a18 clname>
            pointer_to_this <pointer_type 0xfffb60f4830>>
        BLK
        size <integer_cst 0xfffb5ff3000 constant 192>
        unit size <integer_cst 0xfffb5ff3020 constant 24>
        align 32 symtab 0 alias set 22 canonical type 0xfffb60f4788
        domain <integer_type 0xfffb60f4248 type <integer_type 0xfffb60f0000
sizetype>
            SI
            size <integer_cst 0xfffb5ff22e0 constant 32>
            unit size <integer_cst 0xfffb5ff2300 constant 4>
            align 32 symtab 0 alias set -1 canonical type 0xfffb60f4248
precision 32 min <integer_cst 0xfffb5ff2320 0> max <integer_cst 0xfffb5ff24c0
1>>
        pointer_to_this <pointer_type 0xfffb60f48d8>>
    constant addressable asm_written used static ignored BLK file
/home/alan/src/gcc-virgin/libjava/classpath/tools/gnu/classpath/tools/keytool/Main.java
line 0 col 0 size <integer_cst 0xfffb5ff3000 192> unit size <integer_cst
0xfffb5ff3020 24>
    align 32 initial <constructor 0xfffb606b8c8>
    (mem/c:BLK (symbol_ref:SI
("_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook") [flags 0x82]
<var_decl 0xfffb621be98
_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook>) [22
_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook+0 S24 A32]) chain
<var_decl 0xfffb621bfc8
_otable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook>>

I'm not sure how we came to think the array had 3 elements rather than 2. 
Here's that "initial" field.

 <constructor 0xfffb606b8c8
    type <array_type 0xfffb60f4788
        type <record_type 0xfffb60f46e0 BLK
            size <integer_cst 0xfffb5ff2aa0 constant 96>
            unit size <integer_cst 0xfffb5ff2ae0 constant 12>
            align 32 symtab 0 alias set 22 canonical type 0xfffb60f46e0 fields
<field_decl 0xfffb6020a18 clname>
            pointer_to_this <pointer_type 0xfffb60f4830>>
        BLK
        size <integer_cst 0xfffb5ff3000 constant 192>
        unit size <integer_cst 0xfffb5ff3020 constant 24>
        align 32 symtab 0 alias set 22 canonical type 0xfffb60f4788
        domain <integer_type 0xfffb60f4248 type <integer_type 0xfffb60f0000
sizetype>
            SI
            size <integer_cst 0xfffb5ff22e0 constant 32>
            unit size <integer_cst 0xfffb5ff2300 constant 4>
            align 32 symtab 0 alias set -1 canonical type 0xfffb60f4248
precision 32 min <integer_cst 0xfffb5ff2320 0> max <integer_cst 0xfffb5ff24c0
1>>
        pointer_to_this <pointer_type 0xfffb60f48d8>>
    constant lngt 3
    val <constructor 0xfffb606b880 type <record_type 0xfffb60f46e0>
        constant lngt 3
        idx <field_decl 0xfffb6020a18 clname type <pointer_type 0xfffb60f4398>
            unsigned SI file <built-in> line 0 col 0 size <integer_cst
0xfffb5ff22e0 32> unit size <integer_cst 0xfffb5ff2300 4>
            align 32 offset_align 128
            offset <integer_cst 0xfffb5ff2320 constant 0>
            bit offset <integer_cst 0xfffb5ff23a0 constant 0> context
<record_type 0xfffb60f46e0> chain <field_decl 0xfffb6020ab0 name>>
        val <addr_expr 0xfffb6222c80 type <pointer_type 0xfffb60f4398>
            readonly constant arg 0 <var_decl 0xfffb621e498 _Utf259>>
        idx <field_decl 0xfffb6020ab0 name type <pointer_type 0xfffb60f4398>
            unsigned SI file <built-in> line 0 col 0 size <integer_cst
0xfffb5ff22e0 32> unit size <integer_cst 0xfffb5ff2300 4>
            align 32 offset_align 128 offset <integer_cst 0xfffb5ff2320 0> bit
offset <integer_cst 0xfffb5ff22e0 32> context <record_type 0xfffb60f46e0> chain
<field_decl 0xfffb6020b48 signature>>
        val <addr_expr 0xfffb61bdc00 type <pointer_type 0xfffb60f4398>
            readonly constant arg 0 <var_decl 0xfffb61f6290 _Utf111>>
        idx <field_decl 0xfffb6020b48 signature type <pointer_type
0xfffb60f4398>
            unsigned SI file <built-in> line 0 col 0 size <integer_cst
0xfffb5ff22e0 32> unit size <integer_cst 0xfffb5ff2300 4>
            align 32 offset_align 128 offset <integer_cst 0xfffb5ff2320 0>
            bit offset <integer_cst 0xfffb5ff2360 constant 64> context
<record_type 0xfffb60f46e0>>
        val <addr_expr 0xfffb61bdb60 type <pointer_type 0xfffb60f4398>
            readonly constant arg 0 <var_decl 0xfffb61f6030 _Utf110>>>
    val <constructor 0xfffb606b898 type <record_type 0xfffb60f46e0>
        constant lngt 3 idx <field_decl 0xfffb6020a18 clname>
        val <addr_expr 0xfffb61bf200 type <pointer_type 0xfffb60f4398>
            readonly constant arg 0 <var_decl 0xfffb61fe6f8 _Utf166>> idx
<field_decl 0xfffb6020ab0 name> val <addr_expr 0xfffb61bdc00> idx <field_decl
0xfffb6020b48 signature>
        val <addr_expr 0xfffb6222b60 type <pointer_type 0xfffb60f4398>
            readonly constant arg 0 <var_decl 0xfffb621df40 _Utf257>>>
    val <constructor 0xfffb606b8b0 type <record_type 0xfffb60f46e0>
        constant lngt 3 idx <field_decl 0xfffb6020a18 clname>
        val <integer_cst 0xfffb5ff2980 constant 0> idx <field_decl
0xfffb6020ab0 name> val <integer_cst 0xfffb5ff2980 0> idx <field_decl
0xfffb6020b48 signature> val <integer_cst 0xfffb5ff2980 0>>>

[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

[schwab@linux-m68k.org]

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

--- Comment #6 from Andreas Schwab <schwab@linux-m68k.org> 2013-05-02 14:25:09 UTC ---
There is a long standing bug with VLA types (see bug 28865) that has a similar
effect.

[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-05-02 15:17:31 UTC ---
I don't see how this would be related to PR28865, that PR is about .size
directive, if TYPE_SIZE is smaller than DECL_SIZE.  But from what Alan posted
here, that is not the case here, here TYPE_SIZE is the same as DECL_SIZE, 24
bytes both, and the problem is that the CONSTRUCTOR in DECL_INITIAL has 3
entries rather than two.  Perhaps gcj FE bug?

[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aph at gcc dot gnu.org,
                   |                            |tromey at gcc dot gnu.org
   Target Milestone|---                         |4.8.1

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-05-02 18:21:24 UTC ---
So, the decl in question seems to be created by:
#0  build_decl_stat (loc=13046123, code=VAR_DECL, name=0xf42cd7d0,
type=0xf7915840) at ../../gcc/tree.c:4166
#1  0x081bbf87 in gen_indirect_dispatch_tables (type=0xf7973f60) at
../../gcc/java/class.c:472
#2  0x08207f7b in parse_class_file () at ../../gcc/java/jcf-parse.c:1566
#3  0x082091bc in parse_zip_file_entries () at ../../gcc/java/jcf-parse.c:2101

and the DECL_INITIAL for it filled by:

#0  emit_symbol_table (name=0xf42cd7a8, the_table=0xf42cf5c0,
decl_table=0xf42cd938, the_syms_decl=the_syms_decl@entry=0xf42cf61c, 
the_array_element_type=the_array_element_type@entry=0xf790e720,
element_size=element_size@entry=1) at ../../gcc/java/class.c:2965
#1  0x081c7854 in make_class_data (type=0xf7973f60) at
../../gcc/java/class.c:2066
#2  0x081d13ca in finish_class () at ../../gcc/java/class.c:2255
#3  0x082081df in parse_class_file () at ../../gcc/java/jcf-parse.c:1661
#4  0x082091bc in parse_zip_file_entries () at ../../gcc/java/jcf-parse.c:2101

One bug seems to be
one_elt_array_domain_type = build_index_type (integer_one_node);
That name seems to be inconsistent with what it does, build_index_type
(integer_one_node); returns an index type with <min 0> <max 1>, i.e. two
element array.  One element array is build_index_type (integer_zero_node);.

And, either the individual decls need to be created with different types,
depending on how many elements they will have, or at least treated as C []
arrays and at least DECL_SIZE and DECL_SIZE_UNIT need to be updated when
setting DECL_INITIAL.

>From quick skimming, emit_{symbol,assertion}_table are the only callers in
gcc/java/ of build_constructor that don't bother with sizing the array type
appropriately.

[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

[amodra at gmail dot com]

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

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.1                       |---

--- Comment #10 from Alan Modra <amodra at gmail dot com> 2013-05-02 23:04:37 UTC ---
Another fairly easy fix is to make output_object_block() emit the .align
directives instead of padding.  Yes, this covers up the real bug that Jakub has
been looking at, but it might be worth doing for robustness.

[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

[amodra at gmail dot com]

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

--- Comment #11 from Alan Modra <amodra at gmail dot com> 2013-05-03 10:42:12 UTC ---
No, of course that doesn't work.  We make references into the section anchor
block as .LANCHORn+offset, so the items in the block must be exactly where
place_block_symbol() expects them to be.

[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-05-03 15:05:55 UTC ---
$ readelf -Ws obj627/i686-pc-linux-gnu/libjava/.libs/*.so.* | grep
_atable_syms_gnu_classpath_tools_keytool_Main.ShutdownHook
  9864: 00359ca8    24 OBJECT  LOCAL  DEFAULT   23
_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook
  9864: 00359ca8    24 OBJECT  LOCAL  DEFAULT   23
_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook
$ readelf -Ws obj629/i686-pc-linux-gnu/libjava/.libs/*.so.* | grep
_atable_syms_gnu_classpath_tools_keytool_Main.ShutdownHook
  9864: 0035bc60    36 OBJECT  LOCAL  DEFAULT   23
_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook
  9864: 0035bc60    36 OBJECT  LOCAL  DEFAULT   23
_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook

obj627 is trunk without this patch, obj629 with this patch.

[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

[amodra at gmail dot com]

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

--- Comment #15 from Alan Modra <amodra at gmail dot com> 2013-05-04 01:21:50 UTC ---
With this patch I'm still seeing odd trees in place_block_symbol().  In the
following, the type is the correct size (168 bytes), but the var_decl size too
small (48 bytes).  place_block_symbol() uses the var_decl size.  Hmm, I reckon
that's a bug in place_block_symbol().  Shouldn't it be using DECL_INITIAL size?

<var_decl 0xf60797e0
_atable_syms_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer
    type <array_type 0xf61115c0
        type <record_type 0xf6072b80 BLK
            size <integer_cst 0xf5fd1240 constant 192>
            unit size <integer_cst 0xf5fd1200 constant 24>
            align 64 symtab 0 alias set 20 canonical type 0xf6072b80 fields
<field_decl 0xf6072be0 clname>
            pointer_to_this <pointer_type 0xf6072d60>>
        BLK
        size <integer_cst 0xf5fd60a0 constant 1344>
        unit size <integer_cst 0xf5fd6100 constant 168>
        align 64 symtab 0 alias set 20 canonical type 0xf61115c0
        domain <integer_type 0xf6111560 type <integer_type 0xf6070060 sizetype>
            DI
            size <integer_cst 0xf5fd05a0 constant 64>
            unit size <integer_cst 0xf5fd05c0 constant 8>
            align 64 symtab 0 alias set -1 canonical type 0xf6111560 precision
64 min <integer_cst 0xf5fd05e0 0> max <integer_cst 0xf5fd1dc0 6>>
        pointer_to_this <pointer_type 0xf611ec40>>
    constant addressable asm_written static ignored BLK file
/home/amodra/src/gcc-current/libjava/classpath/gnu/java/awt/dnd/peer/gtk/GtkDragSourceContextPeer.java
line 0 col 0
    size <integer_cst 0xf5fd1060 type <integer_type 0xf60700c0 bitsizetype>
constant 384>
    unit size <integer_cst 0xf5fd1280 type <integer_type 0xf6070060 sizetype>
constant 48>
    align 64 initial <constructor 0xf6015ca0>
    (mem/c:BLK (symbol_ref:DI
("_atable_syms_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer") [flags
0x82] <var_decl 0xf60797e0
_atable_syms_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer>) [20
_atable_syms_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer+0 S48 A64])
chain <var_decl 0xf60798a0
_otable_syms_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer>>

[Bug libgcj/57074] [4.8/4.9 Regression] libgcj regression on 32bit Power architecture

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.8.1
            Summary|gcc-4.8.0 libgcj regression |[4.8/4.9 Regression] libgcj
                   |on 32bit Power architecture |regression on 32bit Power
                   |                            |architecture

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-05-06 15:21:07 UTC ---
Author: jakub
Date: Mon May  6 15:09:41 2013
New Revision: 198631

URL: http://gcc.gnu.org/viewcvs?rev=198631&root=gcc&view=rev
Log:
    PR libgcj/57074
    * class.c (emit_symbol_table): Use array type of the
    right size for the_syms_decl and its DECL_INITIAL, instead
    of symbols_array_type.  Set TREE_TYPE (the_syms_decl) to it.
    (emit_assertion_table): Use array type of the right size
    for table_decl and its DECL_INITIAL.

Modified:
    trunk/gcc/java/ChangeLog
    trunk/gcc/java/class.c

Author: jakub
Date: Mon May  6 15:12:53 2013
New Revision: 198632

URL: http://gcc.gnu.org/viewcvs?rev=198632&root=gcc&view=rev
Log:
    PR libgcj/57074
    * class.c (emit_symbol_table): Use array type of the
    right size for the_syms_decl and its DECL_INITIAL, instead
    of symbols_array_type.  Set TREE_TYPE (the_syms_decl) to it.
    (emit_assertion_table): Use array type of the right size
    for table_decl and its DECL_INITIAL.

Modified:
    branches/gcc-4_8-branch/gcc/java/ChangeLog
    branches/gcc-4_8-branch/gcc/java/class.c

Hopefully fixed for 4.8.1+.