-mstrict-align necessary with PPC?
gedare at rtems.org
Mon Jul 15 17:47:55 UTC 2019
On Fri, Jul 5, 2019 at 10:54 AM Michael Davidsaver
<mdavidsaver at gmail.com> wrote:
> In troubleshooting
> 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.
> It looks like some, but not all, RTEMS BSPs provide this flag.
> With relevant exceptions being mvme5500 and beatnik.
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
> 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
> 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
More information about the users