PR 36322/36463

[Janus Weil]

Hi all,

I still haven't managed to get rid of the ICE in testcase5, but I
think I'm getting closer. Attached you find a slightly modified patch,
and a new version of testcase5. The funny thing there is: If
get_funloc is called from within the same module where it is defined,
it gives an ICE, while calling it from a separate program or module
works.

The dump shows the following:

gp ()
{
  get_funloc (make_mess, ..__result);
}

make_mess (character(kind=1)[1:..__result] & __result, integer(kind=4)
.__result, struct array1_integer(kind=4) & y)
{
...
}

get_funloc (void (*<T3bc>) (character(kind=1)[1:.p] &,
integer(kind=4), struct array1_integer(kind=4) &) p, integer(kind=4)
_p)
{
...
}

p ()
{
  static integer(kind=4) options.18[8] = {68, 255, 0, 0, 0, 1, 0, 1};

  _gfortran_set_options (8, (void *) &options.18);
  get_funloc (make_mess);
}

So: The working call inside p looks as expected, while the failing one
in gp has an additional parameter "..__result". The question is just
how and why this gets there. If anybody has some thoughts on this
please let me know ...

Thanks,
Janus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr36322.diff
Type: text/x-patch
Size: 3405 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20081023/94536c32/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testcase5.f90
Type: application/octet-stream
Size: 788 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20081023/94536c32/attachment.obj>