This comment doesn't make any sense to me. AVR does not natively know 16-bit-types, and specifically not atomic access to 16-bit-types, regardless of any alignment.
On a classic AVR CPU, alignment of 16 bit data is not required as 16-bit memory access always evaluates to two 8-bit fetches to two registers.
There is a kind of "alignment restriction", though, when using the movw
instruction available on some AVRs that moves data from one register pair to another - Here the register number of the lower registers must be even. This has nothing to do with memory alignment, though, but may have implications when building a compiler and maybe also when trying to access register content through the register file as memory (lowest 32 RAM addresses), depending on how exactly the compiler is implemented. The compiler might limit itself by keepint the option open to be able to access 16-bit values in registers through a memory access into the register file which would then indeed need word-alignment.
A second kind of "alignment restriction" applies when trying to write to program memory (Flash) - The manual explicitly states that on "SPM instructions, the least significant bit of the address should be cleared". This is understandable, as the AVR's flash is word-addressed according to the minimal instruction size. You can, however, read program memory byte-addressed with the LPM instruction. As direct-access SPM is not supported on all AVRs anyhow, I don't know if this is relevant at all, though. How SPM and "atomic types" would relate to each other escapes meas well - When write accessing program memory, the whole access must be made atomic anyhow, by disabling interrupts. And gcc handles program memory access in libraries anyhow.
Outside this specific cases (register file, program memory store) the AVR has absolutely no problems whatsoever to access word values on odd addresses.