Fortran array indexing on 64-bit targets & snapshot 971023

[Jeffrey A Law]

  In message < 9710241223.AA02380@moene.indiv.nluug.nl >you write:
  > Hi,
  > 
  > It seems that Richard Henderson's `expr.c' (get_inner_reference)  
  > patch didn't make into snapshot 971023.
  > 
  > Was there a compelling reason to exclude it ?
Jim had some questions about it, which nobody has answered yet:

  Jim:
  > The get_inner_reference and f/com.c patch are both doing the same thing,
  > forcing array indexing calculations to sizetype.  If we assume that sizetype
  > is an efficient type, then this is the right thing to do.  If sizetype is
  > larger than a word, then this may result in worse code.  That is probably
  > a case we shouldn't worry about.  One would expect that changing the type of
  > the expression might cause it to compute the wrong value, but I can't see
  > any obvious case where it would be different.  This might be a language bias.
  > The low_bound will always be zero for C and one for Fortran.  It can be
  > other things for a more complicated language like Ada.  It is interesting to
  > note that in expand_expr in the ARRAY_REF case, there is similar code, with
  > a FIXME comment that claims it isn't right.  If this comment is true, then
  > these changes may cause a problem.  If there is a problem, we can probably
  > exclude the failing cases, and still support the Fortran lower_bound = 1
  > case which should always be OK.
The comment about ARRAY_REF in expr.c in particular worries me that we
might be missing some important issue.

I believe Jim is referring to this:

    case ARRAY_REF:
      if (TREE_CODE (TREE_TYPE (TREE_OPERAND (exp, 0))) != ARRAY_TYPE)
        abort ();

      {
        tree array = TREE_OPERAND (exp, 0);
        tree domain = TYPE_DOMAIN (TREE_TYPE (array));
        tree low_bound = domain ? TYPE_MIN_VALUE (domain) : integer_zero_node;
        tree index = TREE_OPERAND (exp, 1);
        tree index_type = TREE_TYPE (index);
        HOST_WIDE_INT i;

        /* Optimize the special-case of a zero lower bound.

           We convert the low_bound to sizetype to avoid some problems
           with constant folding.  (E.g. suppose the lower bound is 1,
           and its mode is QI.  Without the conversion,  (ARRAY
           +(INDEX-(unsigned char)1)) becomes ((ARRAY+(-(unsigned char)1))
           +INDEX), which becomes (ARRAY+255+INDEX).  Oops!)

           But sizetype isn't quite right either (especially if
           the lowbound is negative).  FIXME */

        if (! integer_zerop (low_bound))
          index = fold (build (MINUS_EXPR, index_type, index,
                               convert (sizetype, low_bound)));