PR 19893 & array_ref bug

[Steve Ellcey <sje at cup dot hp dot com>]

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?  That is what I
have in the test case above and when I dump the array_ref for ib[4] I
see that I have an operand 3 and it is zero and I think this is causing
the test failure.  What value should operand 3 have in this situation?
Or should it have been left out?

Steve Ellcey
sje@cup.hp.com