Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ff7ae6c7a7860bca/60213205751117d4 The full program should be checked after fixing this problem. ==28722== Invalid read of size 4 ==28722== at 0x407597: gfc_is_compile_time_shape (array.c:2184) ==28722== by 0x46B11B: resolve_symbol (resolve.c:6811) ==28722== by 0x477326: traverse_ns (symbol.c:3014) ==28722== by 0x4659DF: resolve_types (resolve.c:9179) module other_fun use ISO_C_BINDING implicit none character, allocatable, save :: my_message(:) abstract interface function abstract_fun(x) use ISO_C_BINDING import my_message implicit none integer(C_INT) x(:) character(size(my_message),C_CHAR) abstract_fun(size(x)) end function abstract_fun end interface contains subroutine get_funloc(x) procedure(abstract_fun):: x end subroutine get_funloc end module other_fun
I tried to reduce this as far as I could, and ended up with: subroutine sub(x) abstract interface character function abs_fun() end function end interface procedure(abs_fun):: x end subroutine So, contrary to my expectations, this ICE does not seem to be about ISO_C_BINDING, nor assumed-shape arrays. Instead it seems to be connected to CHARACTER and DUMMY, since it only happens if x is a dummy argument, and abs_fun is character-valued.
valgrind gives the following backtrace: ==19018== Invalid read of size 4 ==19018== at 0x80E71EA: gfc_conv_const_charlen (trans-const.c:179) ==19018== by 0x811B61A: gfc_get_function_type (trans-types.c:2077) ==19018== by 0x80EB30D: build_function_decl (trans-decl.c:1263) ==19018== by 0x80EDEB6: gfc_create_function_decl (trans-decl.c:1820) ==19018== by 0x80EF80C: gfc_generate_function_code (trans-decl.c:3206) ==19018== by 0x80A44DC: gfc_parse_file (parse.c:3601) ==19018== by 0x80D030C: gfc_be_parse_file (f95-lang.c:259) ==19018== by 0x8372C7D: toplev_main (toplev.c:965) ==19018== by 0x811DE11: main (main.c:35)
The fix: Index: gcc/fortran/resolve.c =================================================================== --- gcc/fortran/resolve.c (revision 136234) +++ gcc/fortran/resolve.c (working copy) @@ -7751,6 +7751,7 @@ resolve_symbol (gfc_symbol *sym) { sym->ts.type = sym->ts.interface->ts.type; sym->ts.kind = sym->ts.interface->ts.kind; + sym->ts.cl = sym->ts.interface->ts.cl; sym->attr.function = sym->ts.interface->attr.function; sym->attr.subroutine = sym->ts.interface->attr.subroutine; copy_formal_args (sym, sym->ts.interface);
Subject: Bug 36322 Author: janus Date: Wed Jun 4 21:04:32 2008 New Revision: 136372 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136372 Log: 2008-06-04 Janus Weil <janus@gcc.gnu.org> PR fortran/36322 PR fortran/36275 * resolve.c (resolve_symbol): Correctly copy the interface for a PROCEDURE declaration. 2008-06-04 Janus Weil <janus@gcc.gnu.org> PR fortran/36322 PR fortran/36275 * gfortran.dg/proc_decl_2.f90: Extended. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_decl_2.f90
The test case in comment #0 is fixed by rev. 136372, but when compiling the full program at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ff7ae6c7a7860bca/60213205751117d4 one now gets the error: gp = get_funloc(make_mess,aux) 1 Error: Type/rank mismatch in argument 'x' at (1)
(In reply to comment #5) > The test case in comment #0 is fixed by rev. 136372, but when compiling the > full program [...] I don't see whether the full program is valid or not. (Well, except of the interface in the main program, which is *invalid*.) In any case the following reduced test case produces an ICE. (NAG f95 compiles it.) internal compiler error: in make_decl_rtl, at varasm.c:1297 module other_fun implicit none abstract interface function abstract_fun(x) implicit none integer :: x(:) character(size(x)) abstract_fun end function abstract_fun end interface contains subroutine test() procedure(abstract_fun) foo call get_funloc(foo) end subroutine test subroutine get_funloc(x) procedure(abstract_fun) x end subroutine get_funloc end module other_fun
The dump contains: test () { get_funloc (foo, .x); What I find strange is: a) That foo gets never defined b) That .x is passed (string length?)
This further reduced test case gives a different ICE: abstract interface function abs_fun(x) implicit none integer :: x(:) character(size(x)) abs_fun end function end interface procedure(abs_fun) :: p integer :: i(3) = (/1,2,3/) print *,p(i) end internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:926 The reason for this seems to be that the symbol "x" is missing a backend_decl.
Subject: Bug 36322 Author: janus Date: Sat Nov 1 13:24:03 2008 New Revision: 141515 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141515 Log: 2008-11-01 Janus Weil <janus@gcc.gnu.org> PR fortran/36322 PR fortran/36463 * gfortran.h: New function gfc_expr_replace_symbols. * decl.c (match_procedure_decl): Increase reference count for interface. * expr.c: New functions replace_symbol and gfc_expr_replace_symbols. * resolve.c (resolve_symbol): Correctly copy array spec and char len of PROCEDURE declarations from their interface. * symbol.c (gfc_get_default_type): Enhanced error message. (copy_formal_args): Call copy_formal_args recursively for arguments. * trans-expr.c (gfc_conv_function_call): Bugfix. 2008-11-01 Janus Weil <janus@gcc.gnu.org> PR fortran/36322 PR fortran/36463 * gfortran.dg/proc_decl_17.f90: New. * gfortran.dg/proc_decl_18.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_decl_17.f90 trunk/gcc/testsuite/gfortran.dg/proc_decl_18.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
Rev. 141515 does not fix the complete test case on c.l.f., but most of the troubles it made, including comment #8. Still I'm closing this PR, because PR36463 is about the same c.l.f. code, and will be kept open to track the remaining issues.