On Wed, May 22, 2013 at 07:57:34AM -0600, Sandra Loosemore wrote:
> On 05/22/2013 02:01 AM, Richard Biener wrote:
> >Maybe the idea was to increase the alignment of the struct (without
> >affecting it's layout) when that increases the alignment of a contained
> >array member. Like for
> >
> >struct { int i; int j; float a[1024]; int x; };
> >
> >where aligning to sizeof (int) * 2 would get 'a' a bigger alignment.
>
> In fact, this is what the patch I posted earlier this week does,
> except the alignment it looks for is 16 bytes. In other words, it
> doesn't change the alignment of arrays inside structs (which would
> cause all sorts of compatibility problems), but it checks to see
> whether there is already some array inside the struct aligned on a
> 16-byte offset so that the whole containing struct object would
> benefit from being aligned on a 16-byte boundary.
Right, and I like the patch. However it does have a potential ABI
problem. For example a shared library that exports a variable
affected by this change might do so on a smaller alignment than new
code expects. Fiddling with that variable in a new executable might
give wrong results. Or the PR56564 case of linking C++ relocatable
objects compiled with different compilers might bite us.
Note that rs6000.h DATA_ALIGNMENT already assumes alignment greater
than the ppc64 ABI guarantees for byte arrays. So we're already
guilty of this sin.
--
Alan Modra
Australia Development Lab, IBM
