Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32462

Re: arm-gcc, Cortex-M0+, uint64_t and alignment

Show all headers | View raw

On 20/01/2026 13:26, pozz wrote:
> I just discovered that my arm-gcc assigns an alignment of 8 to a struct 
> with uint64_t member.
> 
> First of all: I can't explain why. Cortex-M0+ shouldn't have any special 
> load/store instructions for 64-bits data. I think the uint64_t variable 
> is *always* accessed with two separate instructions.
> 

There are other Cortex-M devices that /can/ access 64 bit data with a 
single instruction (though not always as an atomic function).

Compilers use family ABI's, not ABI's specifically tuned for exact 
devices.  The EABI for 32-bit ARM says long long's are 8 byte aligned, 
so that's what is used for all targets that use the EABI.  (There's a 
lot to dislike about the EABI - this is not the worst thing.)

> Second thing. Is it safe to force the alignment of such structs to 4 
> with __attribute__((aligned(4)))?
> 

You can't reduce the alignment of a struct or its elements by adding an 
__aligned_ attribute to the struct itself or any of its fields.  The 
best you can do on the struct itself is __attribute__((packed)).  But 
that can come with disadvantages, and inefficient use.

> I have big arrays of structs that contains uint64_t members, so I'm 
> thinking how to save some space.

The best way is to organise the fields so that they are naturally 
aligned, and don't have padding for alignment.  I like "-Wpadded" to 
tell me if there is unexpected padding.


What you /can/ do, however, is define a type that is 64 bits, but 4 byte 
alignment:

typedef uint64_t __attribute__((aligned(4)) uint64_a;

Now you can use "uint64_a" instead of "uint64_t", and it will have 4 
byte alignment.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

arm-gcc, Cortex-M0+, uint64_t and alignment pozz <pozzugno@gmail.com> - 2026-01-20 13:26 +0100
  Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-20 17:07 +0100
    Re: arm-gcc, Cortex-M0+, uint64_t and alignment Grant Edwards <invalid@invalid.invalid> - 2026-01-20 16:41 +0000
      Re: arm-gcc, Cortex-M0+, uint64_t and alignment pozz <pozzugno@gmail.com> - 2026-01-20 18:09 +0100
        Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-20 18:44 +0100
          Re: arm-gcc, Cortex-M0+, uint64_t and alignment pozz <pozzugno@gmail.com> - 2026-01-21 09:11 +0100
            Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-21 10:02 +0100
              Re: arm-gcc, Cortex-M0+, uint64_t and alignment pozz <pozzugno@gmail.com> - 2026-01-21 15:58 +0100
                Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-21 17:13 +0100
                Re: arm-gcc, Cortex-M0+, uint64_t and alignment pozz <pozzugno@gmail.com> - 2026-01-21 17:57 +0100
                Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-22 10:03 +0100
        Re: arm-gcc, Cortex-M0+, uint64_t and alignment Grant Edwards <invalid@invalid.invalid> - 2026-01-20 17:48 +0000
      Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-20 18:41 +0100
        Re: arm-gcc, Cortex-M0+, uint64_t and alignment Grant Edwards <invalid@invalid.invalid> - 2026-01-20 18:10 +0000
          Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-20 22:32 +0100
            Re: arm-gcc, Cortex-M0+, uint64_t and alignment Grant Edwards <invalid@invalid.invalid> - 2026-01-21 03:38 +0000
              Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-21 08:54 +0100
    Re: arm-gcc, Cortex-M0+, uint64_t and alignment pozz <pozzugno@gmail.com> - 2026-01-20 17:55 +0100
      Re: arm-gcc, Cortex-M0+, uint64_t and alignment David Brown <david.brown@hesbynett.no> - 2026-01-20 22:24 +0100

csiph-web