On Mon, 1 Sep 2014 09:14:31 +0800 Peng Fan <van.free...@gmail.com> wrote:
> On 09/01/2014 08:09 AM, Matt Thomas wrote: > > > > On Aug 31, 2014, at 11:32 AM, Joel Sherrill > > <joel.sherr...@oarcorp.com> wrote: > >> I think this is totally expected. You were passed a u8 pointer > >> which is aligned for that type (no restrictions likely). You cast > >> it to a type with stricter alignment requirements. The code is > >> just flawed. Some CPUs handle unaligned accesses but not your ARM. > > > armv7 and armv6 arch except armv6-m support unaligned access. a u8 > pointer is casted to u32 pointer, should gcc take the align problem > into consideration to avoid possible errors? because > -mno-unaligned-access. Using -munaligned-access (or its inverse) isn't enough to make GCC generate code that can perform arbitrary unaligned accesses, because several instructions (e.g. VFP loads/stores or load/store multiple instructions IIRC) must still act on naturally-aligned data even when the hardware flag to enable unaligned accesses is on, and those instructions will still be generated by GCC when they are considered safe, i.e. when not doing explicitly-unaligned accesses in packed structures or similar. It would be *possible* to add an option to the backend to allow arbitrary alignment for any access, I think, but it's not at all clear that it's a good idea, and would certainly negatively affect performance. (If you need unaligned accesses, you can use e.g. memcpy, and that will probably generate good inline code.) Julian