-mstrict-align necessary with PPC?

[Gedare Bloom]

On Fri, Jul 5, 2019 at 10:54 AM Michael Davidsaver
<mdavidsaver at gmail.com> wrote:
>
> All,
>
> In troubleshooting
>
> https://github.com/epics-base/epics-base/issues/29
>
> two questions have come up.
>
>
> 1. Should all PPC BSPs build with -mstrict-align?
>
> 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.
>
> 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
>
I can't see that it would hurt. We don't provide any unaligned access
exception handling, so the option should probably be added to those
BSPs, too.

>
> 2. Is/should __builtin_memcpy() assume destination alignment.
>
> We're seeing a fault from a memcpy() when copies 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.
>
> My understanding is that memcpy() has no requirements on alignment.
>
That's right, you are allowed to call mempcy() with arbitrarily
aligned memory. The behavior appears to be something in GCC assuming a
larger alignment than is actually supported. If mstrict-align fixes
it, then definitely we should be using it in the cfg files.

If you can file a ticket https://devel.rtems.org/wiki/NewTicket to add
the -mstrict-align, and even better submit a patch (best: tested!) we
can try to get it merged in short order.  If you want it in 4.10 it is
still open, and also 4.11, but they will both need separate tickets
(and patches).

Gedare

> However, it should be noted that we have reports of similar code
> faulting after being compiled in MSVC with optimizations enabled.
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users