From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19309 invoked by alias); 14 Mar 2013 18:12:19 -0000 Received: (qmail 19207 invoked by uid 48); 14 Mar 2013 18:11:55 -0000 From: "eleventen at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/56620] New: Memcpy optimization may lead to unaligned access on ARM Thumb Date: Thu, 14 Mar 2013 18:12:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: eleventen at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-03/txt/msg01090.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620 Bug #: 56620 Summary: Memcpy optimization may lead to unaligned access on ARM Thumb Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned@gcc.gnu.org ReportedBy: eleventen@gmail.com Created attachment 29668 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29668 Sample source file Whereas #53016 resolved to an alignment problem with the underlying structures, this is a case where the builtin memcpy optimization emits instructions that may access words on a non-word boundary. The target is an ARM Cortex-M4. The compiler was generated by the summon-gcc project in order to gain access to the hard-float feature of GCC 4.7.2. The problem didn't appear until I implemented faults on unaligned access per the ARM recommendations. The example was compiled with both -O2 and -Os. In both instances the compiler emitted unaligned ldr instructions. Below is pasted the disassembled code at fault. // Here we load the base address of the data array of bytes. a: 4e0c ldr r6, [pc, #48] ; (3c ) c: f44f 74ff mov.w r4, #510 ; 0x1fe 10: 19a3 adds r3, r4, r6 // r3 has 510 - 16*i, an word unaligned offset assuming the data array aligned. 12: 466d mov r5, sp 14: f103 0710 add.w r7, r3, #16 // This next instruction faults. 18: 6818 ldr r0, [r3, #0] 1a: 6859 ldr r1, [r3, #4] 1c: 462a mov r2, r5 1e: c203 stmia r2!, {r0, r1} 20: 3308 adds r3, #8 22: 42bb cmp r3, r7 24: 4615 mov r5, r2 26: d1f7 bne.n 18 3c: 00000000 .word 0x00000000 I recall that a few versions back, GCC started putting stack allocated arrays of bytes on odd or non-word address boundaries. If this is the case, I don't see how memcpy could every legally emit the code above, even if it knew that the array offset was word aligned. While producing the sample, I noticed that it was necessary to have both the unaligned offset like 510 and the indexed offset i*16 to trigger the errant code. Cheers