[Bug fortran/30073] Array out of bounds gives name of RHS array not LHS array

[kargl at gcc dot gnu dot org]

------- Comment #4 from kargl at gcc dot gnu dot org  2010-04-15 19:55 -------
(In reply to comment #3)
> Looking at the -ftree-dump-original output for the code
> in comment #1 finds,
> 
>     if ((logical(kind=4)) __builtin_expect (a.dim[1].ubound < D.1545, 0))
>       {
>          _gfortran_runtime_error_at (&"At line 11 of file a.f90"[1]{lb:1 sz:1},
>           &"Index \'%ld\' of dimension 2 of array \'t\' outside of expected
>           range (%ld:%ld)"[1]{lb: 1 sz: 1}, (<unnamed-signed:32>) D.1545,
>           (<unnamed-signed:32>) a.dim[1].lbound, (<unnamed-signed:32>)
>           a.dim[1].ubound);
>        }
> 
> which shows the correct bounds for 'a' are being checked, but
> the wrong variable name 't' is inserted in error message.  Note,
> this code fragment occurs during the actual act of assignment.
> 

The problem is in trans-array.c(gfc_trans_array_bound_check).

The two blocks of code

  if (!name && se->loop && se->loop->ss && se->loop->ss->expr
      && se->loop->ss->expr->symtree)
    name = se->loop->ss->expr->symtree->name;

  if (!name && se->loop && se->loop->ss && se->loop->ss->loop_chain
      && se->loop->ss->loop_chain->expr
      && se->loop->ss->loop_chain->expr->symtree)
    name = se->loop->ss->loop_chain->expr->symtree->name;

are meant to set 'name' to the relevant variable.  The first
sets 'name' to point at 't' while the second block would set
'name' to point at 'a'.  Clearly, the 2nd 'if ()' fails because
'name' is non-null.

If we look further down, we see

  /* If upper bound is present, include both bounds in the error message.  */
  if (check_upper)
    {
      tmp_lo = gfc_conv_array_lbound (descriptor, n);
      tmp_up = gfc_conv_array_ubound (descriptor, n);

      if (name)
        asprintf (&msg, "Index '%%ld' of dimension %d of array '%s' "
                  "outside of expected RANGE (%%ld:%%ld)", n+1, name);

What we need is a way to take 'descriptor' and find the name of
the entity it is associated with.

tobias and I worked out a possible fix on IRC.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30073