Re: PR 19893 & array_ref bug

[Dorit Naishlos <DORIT at il dot ibm dot com>]

> Steve Ellcey wrote:
> > Most of the gcc.dg/vect/* tests contain something like:
> >
> >    typedef float afloat __attribute__ ((__aligned__(16)));
> >    afloat a[N];
>
> It looks like what is really intended here is to apply the alignment to
> the array type.  The point is that the entire array has to be
> appropriately aligned for the SIMD instructions to work correctly.  It's
> certainly *not* true that the individual array elements must be so
aligned.
>

Right

> So, the right thing to write is:
>
>    typedef float aligned_float_array[N]
__attribute__((__aligned__((16)));
>    aligned_float_array a;
>
> which says that the array should be 16-byte aligned.
>

Another option is to use a union:

typedef int aint __attribute__ ((__aligned__(16)));
union{
  aint aligned_int;
  int ib[N+OFF];
} aligned_union;


> The GCC manual has some confusing language suggesting that arrays of
> aligned objects ought to work, contrary to my earlier statement.  I
> think that's just broken.

Yes, I think this was also the conclusion in this thread:
http://gcc.gnu.org/ml/gcc/2003-09/msg01031.html


dorit


>  For example, if "sizeof (E) * N" is not the
> same as the sizeof an array of N elements of E, all kinds of normal
> invariants of C are going to break.  If the above statement is going to
> be legal at all, then sizeof (afloat) must be equal to (at least) 16,
> which is surely not what the user intended, nor is what GCC actually
does.
>
> > The gcc.dg/compat/struct-layout problems seem to stem from
> > struct-layout-1_generate.c.  In generate_fields() it generates random
> > types, some of these are arrays of some base type.  Then based on
> > another random number we might add an attribute like alignment.  There
> > is no check to ensure that the alignment of the base type is less than
or
> > equal to the size of the base type in those instances where we are
> > creating an array.
>
> That could be fixed by adding the check you suggest, and then just
> discarding the attribute.
>
> --
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com
> (916) 791-8304