Steve Ellcey wrote:
I was looking at PR 19893 (gcc.dg/vect/vect-76 fails on ia64-hpux) and I
think it is caused by a non-platform specific bug, though it may not
cause vect-76 to fail on other platforms.  I was hoping someone might be
able to help me understand what is going on.

Here is a cut down test case (with no vector stuff in it):

typedef int aint __attribute__ ((__aligned__(16)));
aint ib[12];
int ic[12], *x, *y;
int main (void)
{
  x = &ib[4];
  y = &ic[4];
}

If you look at the assembly language generated on IA64 (HP-UX or Linux)
or probably on any platform, you will see that 'y' gets correctly set to
the address of ic[4].  But 'x' gets set to ib[0], instead of ib[4].
Things look good in all the tree dumps but the first rtl dump looks bad
so I believe things are going wrong during expansion.  Looking in
tree.def I see:

/* Array indexing.
   Operand 0 is the array; operand 1 is a (single) array index.
   Operand 2, if present, is a copy of TYPE_MIN_VALUE of the index.
   Operand 3, if present, is the element size, measured in units of
   the alignment of the element type.  */
DEFTREECODE (ARRAY_REF, "array_ref", tcc_reference, 4)

Now I think this the problem is with operand 3. What value should it
have if the alignment is greater than the element size?

This program should generate an error; it's illogical. If the alignment of the element is greater than the element size, then arrays of such a type should be disallowed. Otherwise, stuff in either the compiler or the program itself could make the justified assumption that things of that type are aligned more strictly than they actually are.


--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Reply via email to