From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1175 invoked by alias); 2 May 2013 14:02:02 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 1140 invoked by uid 48); 2 May 2013 14:02:02 -0000 From: "amodra at gmail dot com" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libgcj X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: amodra at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 X-SW-Source: 2013-q2/txt/msg00011.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 --- Comment #5 from Alan Modra 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. unit size align 32 symtab 0 alias set 22 canonical type 0xfffb60f46e0 fields pointer_to_this > BLK size unit size align 32 symtab 0 alias set 22 canonical type 0xfffb60f4788 domain SI size unit size align 32 symtab 0 alias set -1 canonical type 0xfffb60f4248 precision 32 min max > pointer_to_this > 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 unit size align 32 initial (mem/c:BLK (symbol_ref:SI ("_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook") [flags 0x82] ) [22 _atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook+0 S24 A32]) chain > I'm not sure how we came to think the array had 3 elements rather than 2. Here's that "initial" field. unit size align 32 symtab 0 alias set 22 canonical type 0xfffb60f46e0 fields pointer_to_this > BLK size unit size align 32 symtab 0 alias set 22 canonical type 0xfffb60f4788 domain SI size unit size align 32 symtab 0 alias set -1 canonical type 0xfffb60f4248 precision 32 min max > pointer_to_this > constant lngt 3 val constant lngt 3 idx unsigned SI file line 0 col 0 size unit size align 32 offset_align 128 offset bit offset context chain > val readonly constant arg 0 > idx unsigned SI file line 0 col 0 size unit size align 32 offset_align 128 offset bit offset context chain > val readonly constant arg 0 > idx unsigned SI file line 0 col 0 size unit size align 32 offset_align 128 offset bit offset context > val readonly constant arg 0 >> val constant lngt 3 idx val readonly constant arg 0 > idx val idx val readonly constant arg 0 >> val constant lngt 3 idx val idx val idx val >>