On Tue, Nov 29, 2005 at 01:44:44PM +0000, Joern RENNECKE wrote:
> No, it wasn't. The change was supposed to affect structures only.
> As I understand the documentation ,the expected behaviour would be to
> limit the alignment
> to BIGGEST_ALIGNMENT, unless the user has specified a larger alignment
> with the
> aligned attribute.
>
> One possible solution appears to be along the lines of
> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/stor-layout.c.diff?cvsroot=gcc&r1=1.239&r2=1.240
>
> ,
> but with the comment changed to explain what we want to preserve now.
>
> However, I think it is probably better to start out with the right
> alignment, by fix this code
> in layout_type to take BIGGEST_ALIGNMENT into account:
> case VECTOR_TYPE:
> ...
> /* Always naturally align vectors. This prevents ABI changes
> depending on whether or not native vector modes are
> supported. */
> TYPE_ALIGN (type) = tree_low_cst (TYPE_SIZE (type), 0);
If we use MIN (tree_low_cst (TYPE_SIZE (type), 0), BIGGEST_ALIGNMENT)
here, I'm afraid that would be much bigger ABI incompatibility.
Currently, say
typedef char __attribute__((vector_size (64))) v64qi;
is 64 bytes aligned on most arches, even when BIGGEST_ALIGNMENT is much
smaller.
GCC 4.0.x on s390{,x} aligned vector_size 1/2/4/8/64/128/... types
to their size, just vector_size 16 and 32 has been 8 bytes aligned
(BIGGEST_ALIGNMENT).
Not capping to BIGGEST_ALIGNMENT might have issues with some object formats
though, if they don't support ridiculously big aligments.
Jakub
