[Bug fortran/36426] New: Compiling tiny prog: Stack overflow; uses PROCEDURE

[Bug fortran/36426] New: Compiling tiny prog: Stack overflow; uses PROCEDURE

[burnus at gcc dot gnu dot org]

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")
end


-- 
           Summary: Compiling tiny prog: Stack overflow; uses PROCEDURE
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426

[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2008-06-07 16:47 -------
Backtrace:

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:
    case EXPR_FUNCTION:
      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:

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

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


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.3.0 4.4.0
            Summary|Compiling tiny prog: Stack  |Endless loop in
                   |overflow; uses PROCEDURE    |gfc_apply_interface_mapping_
                   |                            |to_expr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426

[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr

[janus at gcc dot gnu dot org]

------- Comment #2 from janus at gcc dot gnu dot org  2008-11-01 14:43 -------
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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426

[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr

[janus at gcc dot gnu dot org]

------- Comment #3 from janus at gcc dot gnu dot org  2008-11-01 14:49 -------
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")
end

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


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-11-01 14:49:48
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426

[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr

[janus at gcc dot gnu dot org]

------- Comment #4 from janus at gcc dot gnu dot org  2008-11-01 14:58 -------
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/))
end


Here the error message is less cryptic:

internal compiler error: in fold_convert, at fold-const.c:2527


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426

[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr

[janus at gcc dot gnu dot org]

------- Comment #5 from janus at gcc dot gnu dot org  2008-11-01 15:03 -------
For both comment #3 and comment #4 the errors disappear if the PROCEDURE
statement is removed and instead the interface is made non-abstract.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426

[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr

[janus at gcc dot gnu dot org]

------- Comment #6 from janus at gcc dot gnu dot org  2008-11-01 19:06 -------
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')


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-11-01 14:49:48         |2008-11-01 19:06:52
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426

[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr

[dominiq at lps dot ens dot fr]

------- Comment #7 from dominiq at lps dot ens dot fr  2008-11-01 20:13 -------
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
end

[ibook-dhum] f90/bug% gfc pr36322_1.f90
f951: internal compiler error: Bus error


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426

[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr

[janus at gcc dot gnu dot org]

------- Comment #8 from janus at gcc dot gnu dot org  2008-11-01 21:57 -------
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
Log:
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.

Added:
    trunk/gcc/testsuite/gfortran.dg/proc_decl_19.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426

[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr

[janus at gcc dot gnu dot org]

------- Comment #9 from janus at gcc dot gnu dot org  2008-11-01 22:00 -------
Fixed with r141522. Closing.


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426