https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #39 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> i don't quite understand this reasoning, i would
> not expect the internal STRICT_ALIGNMENT setting
> to change how types behave (e.g. it might mean
> some code errors out, but the semantics of packed
> and aligned attributes are not changed).
That's not what I said. I only described how modes work on strict-alignment
targets: modes have alignment and you cannot have a type with a mode and the
type's alignment be lower than the mode's alignment.
> i don't see this on arm/sparc, instead i see wrong
> alignment given:
>
> struct __attribute__ ((aligned (8))) S8 { char a[8]; };
> struct __attribute__ ((packed)) S1 { struct S8 s8; };
>
> char a[_Alignof(struct S8)] = {0};
> char b[_Alignof(struct S1)] = {0};
>
> compiles into a size 8 array for a and size 1 array for b,
> so _Alignof is inconsistent, which i'd expect to be an
> error (or warning at least).
I don't see any inconsistency here, __attribute__ ((packed)) is expected to
lower the alignment and takes precedence. Whether or not this is the best
possible implementation is debatable, but it's the historical one. We might
indeed want to warn about that, but the proposed patch is IMO not correct.
Would this patch be sufficient for:
struct __attribute__ ((aligned (4))) S8 { char a[8]; };
struct __attribute__ ((packed)) S1 { struct S8 s8; };
for example?
