PR 36322/36463

[Janus Weil]

Hi all,

as you know PR36463 is one of the last Fortran regressions left on
trunk (even though one might argue that it's not a "real" regression).
It is connected to PR36322, as both of them refer to some sample code
on c.l.f.:

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ff7ae6c7a7860bca/60213205751117d4

I'm right now trying to fix both PRs, and already have a patch which
at least fixes a part of the problems (see attachment). It works with
comment #8 of PR36322, but still gives an ICE on comment #2 of PR36463
(though it is a different one than before). Also the full code on
c.l.f. does not compile yet. However none of the other compilers I
tried (g95 and ifort 11beta) can compile the full code, and I'm not
fully convinced that it's legal after all (surely in some details it
is not).

I also attached a couple of test cases, which demonstrate different
aspects of the problem. The first four are working, the fifth one
still gives an ICE:

testcase5.f90: In function 'gp':
testcase5.f90:16: internal compiler error: in make_decl_rtl, at varasm.c:1297


In general the problem arises for PROCEDURE statements like

PROCEDURE(abs_fun) :: p

where the external procedure 'p' inherits its interface from
'abs_fun', which may be defined like this:

abstract interface
  function abs_fun(x)
    implicit none
    integer :: x(:)
    character(size(x)) abs_fun
  end function
end interface

Here one has to copy the typespec, attributes and formal args from
'abs_fun' to 'p' (which is done in resolve_symbol and has been working
before). In this case also the charlen has to be copied, which is not
trivial, since it's not sufficient to just copy the gfc_expr which
describes the length (in this case "size(x)"), but one also has to
replace the symbol 'x' in this expression, which is a formal arg of
'abs_fun', with a different symbol 'x', which is a formal arg of 'p'!

This not only has to be done for char lengths, but also for array
specs. My test cases may give you some examples.

The patch is free of regressions on i686-pc-linux-gnu.

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).

Cheers,
Janus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr36322.diff
Type: text/x-patch
Size: 2923 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20081020/abd4509a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testcase1.f90
Type: application/octet-stream
Size: 410 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20081020/abd4509a/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testcase2.f90
Type: application/octet-stream
Size: 376 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20081020/abd4509a/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testcase3.f90
Type: application/octet-stream
Size: 544 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20081020/abd4509a/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testcase4.f90
Type: application/octet-stream
Size: 717 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20081020/abd4509a/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testcase5.f90
Type: application/octet-stream
Size: 571 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20081020/abd4509a/attachment-0004.obj>