public inbox for java-prs@sourceware.org
help / color / mirror / Atom feed
From: "amodra at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: java-prs@gcc.gnu.org
Subject: [Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
Date: Thu, 02 May 2013 14:02:00 -0000	[thread overview]
Message-ID: <bug-57074-8172-iw9uIQ8BPb@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-57074-8172@http.gcc.gnu.org/bugzilla/>


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>>>


  parent reply	other threads:[~2013-05-02 14:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-25 19:46 [Bug libgcj/57074] New: " rsa at us dot ibm.com
2013-04-30 20:45 ` [Bug libgcj/57074] " dje at gcc dot gnu.org
2013-05-02  8:18 ` amodra at gmail dot com
2013-05-02  8:54 ` amodra at gmail dot com
2013-05-02 11:35 ` amodra at gmail dot com
2013-05-02 14:02 ` amodra at gmail dot com [this message]
2013-05-02 14:25 ` schwab@linux-m68k.org
2013-05-02 15:17 ` jakub at gcc dot gnu.org
2013-05-02 18:21 ` jakub at gcc dot gnu.org
2013-05-02 23:04 ` amodra at gmail dot com
2013-05-03 10:42 ` amodra at gmail dot com
2013-05-03 15:05 ` jakub at gcc dot gnu.org
2013-05-04  1:21 ` amodra at gmail dot com
2013-05-06 15:21 ` [Bug libgcj/57074] [4.8/4.9 Regression] " jakub at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-57074-8172-iw9uIQ8BPb@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=java-prs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).