[Bug c/56620] New: Memcpy optimization may lead to unaligned access on ARM Thumb

[Bug c/56620] New: Memcpy optimization may lead to unaligned access on ARM Thumb

[eleventen at gmail dot com]

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

[Bug c/56620] Memcpy optimization may lead to unaligned access on ARM Thumb

[eleventen at gmail dot com]

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

[Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb

[pinskia at gcc dot gnu.org]

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?

[Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb

[eleventen at gmail dot com]

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

[Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb

[pinskia at gcc dot gnu.org]

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.

[Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb

[eleventen at gmail dot com]

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.

[Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb

[eleventen at gmail dot com]

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.