https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90061

            Bug ID: 90061
           Summary: ARM cortex-M hard fault on 64 bit sized object store
                    to unaligned address
           Product: gcc
           Version: 7.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: translation
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mike at hamble dot online
  Target Milestone: ---

When generating code for ARM Cortex M4 CPU, and a 64 bit object is stored in
memory to a possibly unaligned address, the code generated will cause an
exception in the case the address is not single word (32 bit aligned).
This fault is dependent on optimisation level in some cases. 

This is because the 64 bit store operation generates either a STD or a STMIA
style instruction which requires 32 bit address alignment. 
Single 32 bit word stores can be unaligned. 

#pragma pack(push, 1)

struct hardwareExample
{
   char x;
   long  a;
   long  b;
} s;

#pragma pack(pop)

If you are accessing hardware or message buffers where the structs map 1:1 to
external message content, you may well try to set the value of  s.a and s.b
close together. The optimiser may try to combine these as a store multiple
operation on an ARM has always been more efficient than independent writes. 

In  -Og mode this code generates two independent 32 bit store unaligned
operations and it works.

In -Os mode this code will combine s.a and s.b store into a single STD or STMIA
instruction and produce a hard fault. 

If the 64 bit value is an atomic type ; long long or double float for instance
then you cannot escape the hard fault. 

In normal code , this problem does not occur as the structure would be created
with the correct alignment for the types, and would be allocated at the correct
alignment for the types concerned. 

It is only where I am handling e.g. a binary GPS protocol. 

There are always workarounds, it is just annoying that -Og code will work and
-Os code will fail (sometimes dependent on arbitrary structure alignment)

Reply via email to