Re: ice-on-valid-code, or invalid

[Janne Blomqvist <jblomqvi at cc dot hut dot fi>]

On Sun, Mar 20, 2005 at 07:28:47PM +0100, Paul Thomas wrote:
> This ICE has already been PR'd - it is the character array that does it in.
> 
> I am nearly there, honest(!), with my namelist submission.  An exchange 
> with Paul Brook last weekend has resoved me to handle derived types and 
> their arrays properly.  Character arrays are one of the things, amongst 
> many, that have been fixed.

Are you saying that your forthcoming patch will fix a large part of
all the char array bugs there are? That would be, well, very swell.

I took a look at PR 15966 last weekend, but unfortunately I didn't
make much headway. I made some ducttape style fixes which fixed the
immediate problem, but instead the problem popped up at another place
with a backtrace that looks almost identical to the one in PR
19269. While this looks discouraging, perhaps the positive side could
be that many character array issues would be related to each other,
and thus one fix could resolve many of them?

Anyway, here's what I found, in case somebody with a better
understanding of the scalarizer can give me a hint:

The root problem in PR 15966 is that in trans-array.c
(gfc_conv_scalarized_array_ref) the gfc_se in the argument list
contains none of the loopinfo and ss stuff. This happens because in
this case the gfc_se being passed is the first created in the chain,
and as gfc_init_se works by copying the loop stuff from the parent,
and parent in this case is NULL, so no loop stuff is ever created.

I found some code to initialize loopinfo and ss in some other place of
the code, and copy-pasted-and-massaged it to
gfc_conv_scalarized_array_ref as follows (the beginning of my modified
function is shown):

  gfc_ss_info *info;
  gfc_ss *ss;
  gfc_loopinfo loop;
  tree index;
  tree tmp;
  int n;

  assert (se != NULL);
  if (se->loop == NULL)
    {
      gfc_init_loopinfo (&loop); 

      /* This is almost certainly wrong.  */
      ss = gfc_walk_expr (ar->as->lower[0]);

      gfc_add_ss_to_loop (&loop, ss);
      gfc_conv_ss_startstride (&loop);
      gfc_conv_loop_setup (&loop);
      gfc_copy_loopinfo_to_se (se, &loop);
      se->ss = loop.ss; /* Huh?  */
    }

So, where is the information required to correctly initialize ss and
loopinfo? E.g. which gfc_expr should be the argument to gfc_walk_expr?
And why does gfc_se have the field ss, since the same can be accessed
via se->loop.ss?

Finally, where is the appropriate place to put this code? I initially
put this into gfc_conv_scalarized_array_ref since that was the top
function in the stack trace. I'm wondering if it would make sense to
initialize loopinfo and ss already in gfc_init_se, then we could
always be sure that it exists?


-- 
Janne Blomqvist