This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
asking for __attribute__((aligned()) clarification
- From: "Markus Fröschle" <markus at mubf dot de>
- To: gcc at gcc dot gnu dot org, gnu-gcc-bug at gnu dot org
- Date: Mon, 19 Aug 2019 14:46:00 +0200
- Subject: asking for __attribute__((aligned()) clarification
All,
this is my first post on these lists, so please bear with me.
My question is about gcc's __attribute__((aligned()). Please consider the following code:
#include <stdint.h>
typedef uint32_t uuint32_t __attribute__((aligned(1)));
uint32_t getuuint32(uint8_t p[]) {
return *(uuint32_t*)p;
}
This is meant to prevent gcc to produce hard faults/address errors on architectures that do not support unaligned access to shorts/ints (e.g some ARMs, some m68k). On these architectures, gcc is supposed to replace the 32 bit access with a series of 8 or 16 bit accesses.
I originally came from gcc 4.6.4 (yes, pretty old) where this did not work and gcc does not respect the aligned(1) attribute for its code generation (i.e. it generates a 'normal' pointer dereference, consequently crashing when the code executes). To be fair, it is my understanding that the gcc manuals never promised this *would* work.
As - at least as far as I can tell - documentation didn't really change regarding lowering alignment for variables and does not appear to say anything specific regarding pointer dereference on single, misaligned variables, I was pretty astonished to see this working on newer gcc versions (tried 6.2 and 7.4), however. gcc appears to even know the differences within an architecture (68000 generates a bytewise copy while ColdFire - that supports unaligned access - copies a 32 bit value).
My question: is this now intended behaviour we can rely on? If yes, can we have documentation upgraded to clearly state that this use case is valid?
Thank you.
Markus