Thanks a lot Alexander for the detailed explanation > Worse, the attribute is documented > to reduce struct alignment down to one byte, and 'ch1' has the same > alignment as the whole struct. This is indeed new information to me, I always thought packed structs had alignment of 1 byte. And non packed (unpacked) structs have alignment equal to the largest alignment of its fields.(I believe my understanding in the case of non packed (unpacked) is correct) So in this case *struct Struct_test *has an alignment of 10 bytes as it's packed, causing it to place *ch1* on a 10 byte aligned address which causes inefficient alignment for *ch1*. Similarly for *ch2* but not for *ch3* as it falls on (10 + 4 + 2 = 16) 4 byte aligned address (its natural alignment) hence no warning for *ch3.* Is my understanding correct? Regards, *Tony* On Thu, Aug 17, 2023 at 6:21 PM Alexander Monakov <amonakov@xxxxxxxxx> wrote: > > On Thu, 17 Aug 2023, Tony Josi via Gcc-help wrote: > > > I would also like to understand the reasoning behind this warning. When a > > struct is packed explicitly it's expected that the padding required for > the > > alignment of the fields will be removed and it might cause inefficient > data > > access. > > It makes sense to warn when a packed attribute has no effect on struct > > layout but I fail to understand why specific fields that are already > > aligned in a struct are warned when the whole struct is packed. > > No, 'ch1' in your example does not keep the original 32b alignment: > the attribute reduces the size of the struct from 12 to 10 bytes, so > it can no longer be 4-byte aligned. Worse, the attribute is documented > to reduce struct alignment down to one byte, and 'ch1' has the same > alignment as the whole struct. > > Alexander >
