Aw: Re: asking for __attribute__((aligned()) clarification

[Markus Fröschle]

Thank you (and others) for your answers. Now I'm just as smart as before, 
however.

Is it a supported, documented, 'long term' feature we can rely on or not?

If yes, I would expect it to be properly documented. If not, never mind.

> Gesendet: Montag, 19. August 2019 um 16:08 Uhr
> Von: "Alexander Monakov" 
> An: "Richard Earnshaw (lists)" 
> Cc: "Paul Koning" , "Markus Fröschle" 
> , gcc@gcc.gnu.org
> Betreff: Re: asking for __attribute__((aligned()) clarification
>
> On Mon, 19 Aug 2019, Richard Earnshaw (lists) wrote:
> 
> > Correct, but note that you can only pack structs and unions, not basic 
> > types.
> > there is no way of under-aligning a basic type except by wrapping it in a
> > struct.
> 
> I don't think that's true. In GCC-9 the doc for 'aligned' attribute has been
> significantly revised, and now ends with
> 
>   When used as part of a typedef, the aligned attribute can both increase and
>   decrease alignment, and specifying the packed attribute generates a 
> warning. 
> 
> (but I'm sure defacto behavior of accepting and honoring reduced alignment on
> a typedef'ed scalar type goes way earlier than gcc-9)
> 
> Alexander
>

asking for __attribute__((aligned()) clarification

[Markus Fröschle]

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 

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