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 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. However, it should be noted that we have reports of similar code faulting after being compiled in MSVC with optimizations enabled. _______________________________________________ users mailing list [email protected] http://lists.rtems.org/mailman/listinfo/users
