https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67701
--- Comment #3 from Julius Werner <jwerner at chromium dot org> --- > I suspect this is an armv7 issue only where there is missing support for > misaligned load/stores. Did a quick test on aarch64 and you're right, neither of the two issues appears there. > Also testvalue is aligned to 1 byte by default so what GCC is doing is > correct as there is no way to do a volatile unaligned loads really. I thought alignment was always tied to a type (at least by default, unless overridden by __attribute__((align)) or the like)? It's true that the expected alignment for testvalue is 1, but I'm not dereferencing testvalue... I'm dereferencing *(volatile unsigned long *)&testvalue. Shouldn't the alignment of that always be 4? (FWIW, _Alignof(*(volatile unsigned long *)&testvalue) evaluates to 4 in both compiler versions.) Another argument: if write32() was defined as a non-inline function in a separate execution unit, this problem would not appear. Should inlining a function really change behavior in this way and produce code that is clearly less efficient (to try to work around a "problem" that the -O0 version of the same code would have never found)?
