PR 36322/36463

[Mikael Morin]

Janus Weil wrote:
> Hi all,
Hi,

> 
> I'd appreciate very much some comments on the patch, and ideas how to
> get rid of the remaining ICE on testcase5 (I just can't figure out its
> origin).
Hum, it fails in the middle-end, so I would say good luck, have fun.
I'm glad I didn't take this PR. :p

I dumped the generated code (-fdump-tree-original) and I saw some
suspicious variables starting with dots.
Like here :

  __result_gp = get_funloc (make_mess, ..__result);

I think variables are named as follows (please someone confirms) :
	<name>.<numeric code>
for exemple :
	tmp.3
so we can have code like this (in this example, tmp.3 is an array
descriptor):
	tmp.3.offset = 0;

So I guess that this "..__result" should be understood as
"<unset>.<unset>.__result".

At least this gives you some places where you should investigate, but
you may need the help of middle-end gurus to get more valuable comments.



About your patch, I didn't look closely at it, but I would say that you
don't need the '&' before replace_symbol in the call to gfc_traverse_expr.

And the gfc_expr_replace_symbols function looks like gfc_traverse_expr
is changing i's value. I think that it would be clearer like this:
{
  gfc_traverse_expr (expr, dest, replace_symbol, 0);
  return 0;
}
While you are at it, you can change the return value to void because it
is always 0.

Those are only details anyway.

> 
> Cheers,
> Janus
> 
Cheers too
Mikael