Re: s390{,x} ABI incompatibility between gcc 4.0 and 4.1

[Jakub Jelinek <jakub at redhat dot com>]

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