"Devang Patel" <[EMAIL PROTECTED]> writes: > > > > > > http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00167.html > > > > This patch looks wrong to me. I don't understand how it could be > > correct in the presence of __attribute__ ((aligned (N))). It checks > > TYPE_PACKED but not TYPE_ALIGN or TYPE_USER_ALIGN. The default hook > > assumes that objects larger than pointers are not naturally aligned, > > which does not make sense to me: given a type, we know the alignment, > > and we should use that. > > This patch for the cases when alignment is *not known* at > compile time. > > is_packed is for targets that support various alignment rules for packed > structs. > > See > http://gcc.gnu.org/ml/gcc/2005-12/msg00390.html > for more discussion on this topic.
Thanks for the pointer. It seems to me that the way to fix this problem is to know the alignment. For any type there is the ideal alignment and there is the minimum supported alignment. Currently TYPE_ALIGN for a scalar type holds the ideal alignment. I think that given an arbitrary pointer with no alignment attributes, we may correctly assume that that pointer has the minimum supported alignment. So what we need is a backend hook to return the minimum supported alignment for a type. The ideal alignment and the minimum supported alignment will always be the same *except* when the target defines BIGGEST_FIELD_ALIGNMENT or ADJUST_FIELD_ALIGN. So I think a better fix here would be a target hook or macro which returns the minimum supported alignment given a type. If it is a hook, the default version could use BIGGEST_FIELD_ALIGNMENT. Special versions would be required for each target which defines ADJUST_FIELD_ALIGN (there are only three). Ian
