This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]