Thanks again for correcting.
> The warning is (quite cryptically) telling you about the fields that
remain
> aligned relative to the struct (which itself may be at an odd address).
So basically the compiler is trying to warn that with the packed attribute
the fields that are aligned relative to the struct can be aligned
inefficiently as
the alignment of the entire struct is now 1.
If that's the case, I'm not sure what's the purpose of this warning, isn't
it quite expected?
Regards,
*Tony*
On Thu, Aug 17, 2023 at 11:45 PM Alexander Monakov <amonakov@xxxxxxxxx>
wrote:
>
> On Thu, 17 Aug 2023, Tony Josi via Gcc-help wrote:
>
> > 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.
>
> That's correct.
>
> > 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)
>
> Also correct.
>
> > So in this case *struct Struct_test *has an alignment of 10 bytes
>
> No, it has size 10, alignment 1.
>
> > as it's packed, causing it to place *ch1* on a 10 byte aligned address
> which
>
> No, ch1 has alignment 1 (non-power-of-two alignment doesn't make sense)
>
> > 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?
>
> The warning is (quite cryptically) telling you about the fields that remain
> aligned relative to the struct (which itself may be at an odd address).
> Consider
>
> struct __attribute__((packed)) Struct_test
> {
> uint32_t ch1;
> uint16_t ch2;
> uint32_t ch3;
> uint16_t ch4;
> uint32_t ch5;
> };
>
> All fields except ch3 are diagnosed.
>
> Alexander
>
