Bug 36322 - ICE with PROCEDURE using a complicated interface
ICE with PROCEDURE using a complicated interface
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.4.0
: P3 normal
: ---
Assigned To: janus
: ice-on-valid-code
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-24 16:14 UTC by Tobias Burnus
Modified: 2008-11-01 13:33 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-05-31 11:45:04


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2008-05-24 16:14:33 UTC
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
Comment 1 janus 2008-05-31 11:03:38 UTC
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.
Comment 2 janus 2008-05-31 11:18:46 UTC
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)
Comment 3 janus 2008-05-31 11:45:03 UTC
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);
Comment 4 janus 2008-06-04 21:05:18 UTC
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

Comment 5 janus 2008-06-04 21:17:49 UTC
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)
Comment 6 Tobias Burnus 2008-06-04 22:45:02 UTC
(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
Comment 7 Tobias Burnus 2008-06-04 22:46:45 UTC
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?)
Comment 8 janus 2008-06-04 23:37:12 UTC
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.
Comment 9 janus 2008-11-01 13:25:30 UTC
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

Comment 10 janus 2008-11-01 13:33:31 UTC
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.