Jakub Jelinek - Re: s390{,x} ABI incompatibility between gcc 4.0 and 4.1 (original) (raw)

This is the mail archive of the gcc@gcc.gnu.orgmailing 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]

On Tue, Nov 29, 2005 at 10:01:25PM +0000, Joern RENNECKE wrote:

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).

That sounds very strange. Is there a rationale for that, or is this a SNAFU?

It is just a side-effect of the 3.4/4.0 code - if there was a supported integer mode on the target for the requested size, then alignment of that mode was used (and mode alignments are at most BIGGEST_ALIGNMENT). If no integer mode was supported for that size, it would use the earlier alignment, i.e. vector_size. Unfortunately, while say vector_size (64) etc. vectors are IMHO very unlikely, vector_size (16) will occurr in user programs from time to time and thus the ABI incompatibility might affect existing programs. We can document the incompatibility as a feature (after all, getting rid of that alignment anomaly on s390{,x} wouldn't be a bad thing I guess).

Not capping to BIGGEST_ALIGNMENT might have issues with some object formats though, if they don't support ridiculously big aligments.

We have MAX_OFILE_ALIGNMENT for that.

But is it used for vector type alignments?

Jakub

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