public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/56620] New: Memcpy optimization may lead to unaligned access on ARM Thumb
@ 2013-03-14 18:12 eleventen at gmail dot com
2013-03-14 18:13 ` [Bug c/56620] " eleventen at gmail dot com
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: eleventen at gmail dot com @ 2013-03-14 18:12 UTC (permalink / raw)
To: gcc-bugs
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 <copy_unaligned+0x3c>)
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 <copy_unaligned+0x18>
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/56620] Memcpy optimization may lead to unaligned access on ARM Thumb
2013-03-14 18:12 [Bug c/56620] New: Memcpy optimization may lead to unaligned access on ARM Thumb eleventen at gmail dot com
@ 2013-03-14 18:13 ` eleventen at gmail dot com
2013-03-14 18:20 ` [Bug target/56620] " pinskia at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: eleventen at gmail dot com @ 2013-03-14 18:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620
--- Comment #1 from eleventen at gmail dot com 2013-03-14 18:13:03 UTC ---
Created attachment 29669
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29669
Sample source object
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb
2013-03-14 18:12 [Bug c/56620] New: Memcpy optimization may lead to unaligned access on ARM Thumb eleventen at gmail dot com
2013-03-14 18:13 ` [Bug c/56620] " eleventen at gmail dot com
@ 2013-03-14 18:20 ` pinskia at gcc dot gnu.org
2013-03-14 18:26 ` eleventen at gmail dot com
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: pinskia at gcc dot gnu.org @ 2013-03-14 18:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target|ARM Thumb Cortex-M4 |
Host|x86 |
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-03-14 18:20:03 UTC ---
Can you mention the exact configure option which was used to build GCC (gcc -v
should give that)? Can you also say what option you passed to GCC?
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb
2013-03-14 18:12 [Bug c/56620] New: Memcpy optimization may lead to unaligned access on ARM Thumb eleventen at gmail dot com
2013-03-14 18:13 ` [Bug c/56620] " eleventen at gmail dot com
2013-03-14 18:20 ` [Bug target/56620] " pinskia at gcc dot gnu.org
@ 2013-03-14 18:26 ` eleventen at gmail dot com
2013-03-14 20:33 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: eleventen at gmail dot com @ 2013-03-14 18:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620
--- Comment #3 from Marc Singer <eleventen at gmail dot com> 2013-03-14 18:26:02 UTC ---
The compiler was built as follows:
elf@cerise ~/memcpy-bug > /opt/gcc/arm-none-eabi/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/arm-none-eabi/bin/gcc
Target: arm-none-eabi
Configured with: ../gcc-4.7.2/configure --target=arm-none-eabi
--prefix=/opt/gcc --enable-multilib --enable-languages=c,c++ --with-newlib
--with-gnu-as --with-gnu-ld --disable-nls --disable-shared --disable-threads
--with-headers=newlib/libc/include --disable-libssp --disable-libstdcxx-pch
--disable-libmudflap --disable-libgomp --disable-werror --with-system-zlib
--disable-newlib-supplied-syscalls
Thread model: single
gcc version 4.7.2 (GCC)
The invoking command line, available at the top of the sample source file, is
reproduced here for clarity.
arm-none-eabi-gcc -std=c99 -g -Os -c -mcpu=cortex-m3 -mthumb memcpy-test.c -o
memcpy-test.o
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb
2013-03-14 18:12 [Bug c/56620] New: Memcpy optimization may lead to unaligned access on ARM Thumb eleventen at gmail dot com
` (2 preceding siblings ...)
2013-03-14 18:26 ` eleventen at gmail dot com
@ 2013-03-14 20:33 ` pinskia at gcc dot gnu.org
2013-03-14 21:06 ` eleventen at gmail dot com
2013-03-14 21:36 ` eleventen at gmail dot com
5 siblings, 0 replies; 7+ messages in thread
From: pinskia at gcc dot gnu.org @ 2013-03-14 20:33 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-03-14 20:33:27 UTC ---
I think you are required to use -mno-unaligned-access for armv7 targets where
you doing bare metal work without the page table setup.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb
2013-03-14 18:12 [Bug c/56620] New: Memcpy optimization may lead to unaligned access on ARM Thumb eleventen at gmail dot com
` (3 preceding siblings ...)
2013-03-14 20:33 ` pinskia at gcc dot gnu.org
@ 2013-03-14 21:06 ` eleventen at gmail dot com
2013-03-14 21:36 ` eleventen at gmail dot com
5 siblings, 0 replies; 7+ messages in thread
From: eleventen at gmail dot com @ 2013-03-14 21:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620
Marc Singer <eleventen at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
--- Comment #5 from Marc Singer <eleventen at gmail dot com> 2013-03-14 21:05:42 UTC ---
Indeed the compiler documentation states that the ARMv6M and older default to
no unaligned accesses, but that changed in v7.
Thanks.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb
2013-03-14 18:12 [Bug c/56620] New: Memcpy optimization may lead to unaligned access on ARM Thumb eleventen at gmail dot com
` (4 preceding siblings ...)
2013-03-14 21:06 ` eleventen at gmail dot com
@ 2013-03-14 21:36 ` eleventen at gmail dot com
5 siblings, 0 replies; 7+ messages in thread
From: eleventen at gmail dot com @ 2013-03-14 21:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620
--- Comment #6 from Marc Singer <eleventen at gmail dot com> 2013-03-14 21:35:54 UTC ---
For the sake of posterity, the Cortex-M3 and M4 do handle unaligned accesses
properly in hardware though with the expected performance penalty. It is the
fact that I enforced alignment by making configuration changes to the MCU that
caused the issue. And I did so on the recommendation of ARM which isn't
universally justified in the Cortex TRM:
To ensure a smooth transition, ARM recommends that code designed to operate on
other Cortex-M profile processor architectures obey the following rules and
configure the Configuration and Control Register (CCR) appropriately:
• • •
use word transfers only to access registers in the NVIC and System Control
Space (SCS). treat all unused SCS registers and register fields on the
processor as Do-Not-Modify.
configure the following fields in the CCR:
— STKALIGN bit to 1
— UNALIGN_TRP bit to 1
— Leave all other bits in the CCR register as their original value.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-03-14 21:36 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-14 18:12 [Bug c/56620] New: Memcpy optimization may lead to unaligned access on ARM Thumb eleventen at gmail dot com
2013-03-14 18:13 ` [Bug c/56620] " eleventen at gmail dot com
2013-03-14 18:20 ` [Bug target/56620] " pinskia at gcc dot gnu.org
2013-03-14 18:26 ` eleventen at gmail dot com
2013-03-14 20:33 ` pinskia at gcc dot gnu.org
2013-03-14 21:06 ` eleventen at gmail dot com
2013-03-14 21:36 ` eleventen at gmail dot com
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).