[RTEMS Project] #3767: Should all PPC BSPs build with -mstrict-align?

[RTEMS trac]

#3767: Should all PPC BSPs build with -mstrict-align?
---------------------------------+--------------------
  Reporter:  Michael Davidsaver  |      Owner:  (none)
      Type:  defect              |     Status:  new
  Priority:  normal              |  Milestone:
 Component:  arch/powerpc        |    Version:
  Severity:  normal              |   Keywords:
Blocked By:                      |   Blocking:
---------------------------------+--------------------
 As requested by Gedare Bloom.

 https://lists.rtems.org/pipermail/users/2019-July/033400.html

 Based on the description in the GCC documentation, I would expect
 this to be needed unless the target handles alignment exceptions
 to fixup unaligned access (which RTEMS doesn't).

 https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-
 Options.html#RS_002f6000-and-PowerPC-Options

 It looks like some, but not all, RTEMS BSPs provide this flag.
 With relevant exceptions being mvme5500 and beatnik.

 https://github.com/RTEMS/rtems/search?q=-mstrict-align&type=Code

 We're seeing a fault from a memcpy() when a copy of a double into an
 unaligned byte buffer is optimized to the builtin.

 > char *buf = ...;
 > double value = ...;
 > memcpy(buf, &value, sizeof(value));

 In the absence of -mstrict-align this memcpy() is sometimes ("-mcpu=7400
 -O3")
 optimized to a single "stfd" which faults because 'buf' is not 8 byte
 aligned.

 I feel like there is a bug here.  My question is whether this is the
 builtin making an overzealous assumption about destination alignment,
 or our usage of memcpy() being incorrect somehow.  Should this be reported
 as a GCC bug as well?

--
Ticket URL: <http://devel.rtems.org/ticket/3767>
RTEMS Project <http://www.rtems.org/>
RTEMS Project