> So don't lie to GCC then? You specify
>
> struct X { char c; int i; } __attribute__((packed)) x;
>
> and expect that GCC knows x.i is aligned to 4 bytes!?
The actual header is much more complex than this trivial example.
It also fails with this example, where the port_status[] array *is*
obviously aligned, but the "packed" attribute *also* makes gcc think
the *structure* is misaligned, which is not the case:
struct ehci_regs {
char x;
short y;
char z;
unsigned int port_status[0];
} __attribute__ ((packed));
The line that fails is the next one:
return *(volatile unsigned int *)status_reg;
The user has explicitly told gcc that the pointer is a valid
pointer-to-int. How else can the user tell gcc it's wrong about
alignment? I mean, without changing zillions of released kernel
header files?
> Or declare it a bug in volatile handling (which is, after all, not
> very well defined)
I've been working on "fixing" volatile to mean "do what I tell you"
but historically, "volatile" has had lots of leeway in gcc.
> and simply throw away any alignment information we have in that case
> (which would make it an expander bug I guess, unless the arm target does
> something special here).
Various targets choose to honor volatile over gcc's natural bitfield
access rules, and yes, we're doing it in the expander. Other volatile
access rules could be applied there too.
