Bug 36426 - Endless loop in gfc_apply_interface_mapping_to_expr
Endless loop in gfc_apply_interface_mapping_to_expr
Product: gcc
Classification: Unclassified
Component: fortran
: P3 normal
: ---
Assigned To: janus
: ice-on-valid-code
Depends on:
  Show dependency treegraph
Reported: 2008-06-02 20:51 UTC by Tobias Burnus
Modified: 2008-11-01 22:00 UTC (History)
2 users (show)

See Also:
Known to work:
Known to fail: 4.3.0 4.4.0
Last reconfirmed: 2008-11-01 19:06:52


Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2008-06-02 20:51:37 UTC
The following valid program causes gfortran to use more and more stack memory.

abstract interface
  function foo(x)
   character(len=len(x)) :: foo,x
  end function foo
end interface
character(len=20) :: str
procedure(foo) :: bar
str = bar("Hello")
Comment 1 Tobias Burnus 2008-06-07 16:47:55 UTC

in gfc_getmem (n=40) at gcc/fortran/misc.c:37
in gfc_get_interface_mapping_charlen   at gcc/fortran/trans-expr.c:1485
in gfc_apply_interface_mapping_to_expr at gcc/fortran/trans-expr.c:1920
in gfc_apply_interface_mapping_to_expr at gcc/fortran/trans-expr.c:1955
[... last two lines repeat several times ...]
in gfc_finish_interface_mapping        at gcc/fortran/trans-expr.c:1695
in gfc_conv_function_call              at gcc/fortran/trans-expr.c:2637

In gfc_apply_interface_mapping_to_expr, first a EXPR_FUNCTION with expr->name "__len_1_i4" is mapped; then a BT_CHARACTER EXPR_VARIABLE, then a function "__len_1_i4" then ...

Line 1955 is:
      for (actual = expr->value.function.actual; actual; actual = actual->next)
        gfc_apply_interface_mapping_to_expr (mapping, actual->expr);

Line 1920 is:
  if (expr->ts.type == BT_CHARACTER && expr->ts.cl)
      expr->ts.cl = gfc_get_interface_mapping_charlen (mapping, expr->ts.cl);

  * * *

The essential part of the bug is that the length of the return value depends on the dummy argument. Reduced test:

    function foo(x)
     character(len=len(x)) :: foo,x
    end function foo
  end interface
  character(len=20) :: str
  str = foo("Hello")

Important is that both foo and x are "len(x)", if x has len=*, it works.

At the end the call looks / should look like
  foo ((character(kind=1)[1:5] *) &str.1, 5, D.1017, 5);
(as generated with "(len=*) :: x")
Comment 2 janus 2008-11-01 14:43:15 UTC
I'm not completely convinced yet that the code in comment #0 is valid. While g95 accepts it, ifort 11.0 beta says:

c0.f90(4): error #6362: The data types of the argument(s) are invalid.   [LEN]
   character(len=len(x)) :: foo,x
c0.f90(4): error #6415: This name cannot be assigned this data type because it conflicts with prior uses of the name.   [X]
   character(len=len(x)) :: foo,x
compilation aborted for c0.f90 (code 1)

What I'm worrying about: Is it allowed to use len(x) in the declaration of x?
Comment 3 janus 2008-11-01 14:49:47 UTC
Here is a modified version of comment #0:

abstract interface
  function foo(x)
   character(len=*) :: x
   character(len=len(x)) :: foo
  end function foo
end interface
character(len=20) :: str
procedure(foo) :: bar
str = bar("Hello")

While this is accepted by both g95 and ifort 11 beta, gfortran-4.4 gives:

/tmp/ccAEUsfi.s: Assembler messages:
/tmp/ccAEUsfi.s:29: Error: junk `(intrinsic)_MOD_len' after expression
Comment 4 janus 2008-11-01 14:58:42 UTC
A variant of comment #3 which gives a different error:

abstract interface
  function foo(x,y)
   character(len=*) :: x
   integer y(:)
   character(len=size(y)) :: foo
  end function foo
end interface
character(len=20) :: str
procedure(foo) :: bar
str = bar("Hello",(/1,2,3/))

Here the error message is less cryptic:

internal compiler error: in fold_convert, at fold-const.c:2527
Comment 5 janus 2008-11-01 15:03:02 UTC
For both comment #3 and comment #4 the errors disappear if the PROCEDURE statement is removed and instead the interface is made non-abstract.
Comment 6 janus 2008-11-01 19:06:51 UTC
The following patch fixes comment #3 and comment #4:

Index: gcc/fortran/expr.c
--- gcc/fortran/expr.c	(revision 141520)
+++ gcc/fortran/expr.c	(working copy)
@@ -3511,12 +3511,11 @@ static bool
 replace_symbol (gfc_expr *expr, gfc_symbol *sym, int *i ATTRIBUTE_UNUSED)
   if ((expr->expr_type == EXPR_VARIABLE || expr->expr_type == EXPR_FUNCTION)
-      && expr->symtree->n.sym->ns != sym->formal_ns
-      && expr->symtree->n.sym->attr.dummy)
+      && expr->symtree->n.sym->ns == sym->ts.interface->formal_ns)
       gfc_symtree *stree;
       gfc_get_sym_tree (expr->symtree->name, sym->formal_ns, &stree);
-      stree->n.sym->attr.referenced = expr->symtree->n.sym->attr.referenced;
+      stree->n.sym->attr = expr->symtree->n.sym->attr;
       expr->symtree = stree;
   return false;
Index: gcc/fortran/resolve.c
--- gcc/fortran/resolve.c	(revision 141515)
+++ gcc/fortran/resolve.c	(working copy)
@@ -8936,6 +8936,9 @@ resolve_symbol (gfc_symbol *sym)
 	      sym->ts.cl->resolved = ifc->ts.cl->resolved;
 	      sym->ts.cl->length = gfc_copy_expr (ifc->ts.cl->length);
 	      gfc_expr_replace_symbols (sym->ts.cl->length, sym);
+	      /* Add charlen to namespace.  */
+	      sym->ts.cl->next = sym->formal_ns->cl_list;
+	      sym->formal_ns->cl_list = sym->ts.cl;
       else if (sym->ts.interface->name[0] != '\0')
Comment 7 Dominique d'Humieres 2008-11-01 20:13:37 UTC
With the patch in comment #6 the following code gives an ICE:

subroutine sub(x)
  abstract interface
    character function abs_fun()
    end function
  end interface
  procedure(abs_fun):: x
end subroutine

[ibook-dhum] f90/bug% gfc pr36322_1.f90
f951: internal compiler error: Bus error
Comment 8 janus 2008-11-01 21:57:51 UTC
Subject: Bug 36426

Author: janus
Date: Sat Nov  1 21:56:27 2008
New Revision: 141522

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141522
2008-11-01  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/36426
	* expr.c (replace_symbol): Replace all symbols which lie in the
	formal namespace of the interface and copy their attributes.
	* resolve.c (resolve_symbol): Add charlen to namespace.

2008-11-01  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/36426
	* gfortran.dg/proc_decl_19.f90: New.


Comment 9 janus 2008-11-01 22:00:26 UTC
Fixed with r141522. Closing.