This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix 21166
On Fri, Apr 29, 2005 at 12:32:44PM +0100, Nathan Sidwell wrote:
> So, it's a request to stor-layout to pack the field as close as
> possible to its predecessor. What should it mean after layout
> is complete? Should it mean
> 1) the user asked for this to be packed densely, or
> 2) this field is not necessarily aligned
Both 1 and 2, normally.
Now, if the structure is aligned for *other* reasons, e.g.
template<typename T>
struct S {
int x __attribute__((packed));
T y;
};
This structure has alignment based on 'y'. We can, without changing
the meaning of the program, boost the alignment of 'x' back from 1 to
that of 'y' (taking into account the offset of x, 0 in this case).
> IMO the real problem is that we don't propagate unalignedness in the
> type system correctly (we should treat it in a way similar to constness).
> The type of the field which is packed should be changed from plain 'T' to
> 'T __attribute((aligned(1)))' (and of course not adding that attribute if
> the alignment of T was already 1). If we did that, DECL_PACKED would go
> away.
Agreed. I've always thought it completely unintuitive that plain
__attribute__((aligned(2))) is supposed to be ignored if the natural
alignment is greater than 2; you're supposed to use packed as well.
r~