[Bug target/85616] ARM target using -O2 may cause unaligned access

[denis_second at hotmail dot com]

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

Denis Roux  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #6 from Denis Roux  ---
Ok this is a fair assumption from gcc and the result makes total sense. Using
the suggested new type provides code with expected result.

Thank you for taking the time and providing valuable input regarding this
issue.

[Bug target/85616] ARM target using -O2 may cause unaligned access

[denis_second at hotmail dot com]

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

--- Comment #4 from Denis Roux  ---
I agree that the given example code is breaking the C strict aliasing rule.
However, I do not believe that the issue I'm reporting is related to aliasing.
Further more, adding -fno-strict-aliasing option do not alter the output.

The issue I'm having with the optimized code is that it got optimized from 2
store instructions that do not have alignment restriction into 1 multi-store
instruction the does have alignment restriction. I would have expected that the
optimization would have occurred only if the alignment was guaranteed to be
respected.

[Bug target/85616] New: ARM target using -O2 may cause unaligned access

[denis_second at hotmail dot com]

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

Bug ID: 85616
   Summary: ARM target using -O2 may cause unaligned access
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis_second at hotmail dot com
  Target Milestone: ---

Created attachment 44052
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44052&action=edit
c file

The 32-bit arm target using "-O2" optimization option may combine single stores
into a multi store without respecting the alignment requirement of stm
instruction.
ARM reference:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html

The following output was produced using gcc version 6.3.1

simple code to recreate the issue:

extern "C" bool bugTest(unsigned char *buf_start)
{
register unsigned int item1 asm("r2") = *(unsigned int *) &buf_start[12];
register unsigned int item2asm("r3")= *(unsigned int *) &buf_start[16];
*(unsigned int *) &buf_start[0] = item1;
*(unsigned int *) &buf_start[4] = item2;

return 1;
}

gcc -march=armv7-a -O2 -o stm.o stm.c

objdump stm.o

 :
   0:   e590200cldr r2, [r0, #12]
   4:   e5903010ldr r3, [r0, #16]
   8:   e88cstm r0, {r2, r3} <-- causing unaligned access if
buf_start wasn't on a word boundary
   c:   e12fff1ebx  lr


If I turn off peephole2 optimization I get the expected assembly

gcc -march=armv7-a -O2 -fno-peephole2 -o stm.o stm.c

 :
   0:   e590200cldr r2, [r0, #12]
   4:   e5903010ldr r3, [r0, #16]
   8:   e5802000str r2, [r0]
   c:   e5803004str r3, [r0, #4]
  10:   e12fff1ebx  lr