Bug 40743 - [4.5 Regression] ICE when compiling iso_varying_string.f95 at revision 149591
Summary: [4.5 Regression] ICE when compiling iso_varying_string.f95 at revision 149591
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: 4.5.0
Assignee: janus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-14 08:54 UTC by Dominique d'Humieres
Modified: 2009-07-15 08:47 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-07-14 16:53:59


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dominique d'Humieres 2009-07-14 08:54:28 UTC
At revision 149591, compiling iso_varying_string.f95 gives the following error:

[ibook-dhum] f90/bug% gfc -c iso_varying_string.f95
iso_varying_string.f95:2548.29:

end module iso_varying_string
                             1
Internal Error at (1):
resolve_code(): Bad statement code

Probably due (or uncovered) by revision 149586.

Note that the same error occurs when compiling the codes in pr40440#0 and pr40440#2.
Comment 1 Tobias Burnus 2009-07-14 09:46:29 UTC
> Probably due (or uncovered) by revision 149586

That's: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149586
2009-07-13  Janus Weil  <janus@gcc.gnu.org>
	PR fortran/40646
Comment 2 Tobias Burnus 2009-07-14 09:47:41 UTC
> [ibook-dhum] f90/bug% gfc -c iso_varying_string.f95

I assume that's the file: http://www.fortran.com/iso_varying_string.f95
Comment 3 Dominique d'Humieres 2009-07-14 10:54:12 UTC
> I assume that's the file: http://www.fortran.com/iso_varying_string.f95

yes.
Comment 4 janus 2009-07-14 13:20:29 UTC
Here is a minimal test case:

  implicit none

  type :: varying_string
  end type

  interface assignment(=)
     procedure op_assign_VS_CH
  end interface

contains

  subroutine op_assign_VS_CH (var, exp)
    type(varying_string), intent(out) :: var
    character(LEN=*), intent(in)      :: exp
  end subroutine

  subroutine split_VS
    type(varying_string) :: string
    call split_CH(string)
  end subroutine

  subroutine split_CH (string)
    type(varying_string) :: string
    string = ""
  end subroutine

end
Comment 5 janus 2009-07-14 13:38:08 UTC
Backtrace for the code in comment #4:

#0  resolve_code (code=0x2f26580, ns=0x2f25520) at /home/jweil/gcc45/trunk/gcc/fortran/resolve.c:7168
#1  0x0000000000512703 in resolve_codes (ns=0x2f25520) at /home/jweil/gcc45/trunk/gcc/fortran/resolve.c:10966
#2  0x0000000000512640 in resolve_codes (ns=0x2f1f4f0) at /home/jweil/gcc45/trunk/gcc/fortran/resolve.c:10956
#3  0x00000000005127ef in gfc_resolve (ns=0x2f1f4f0) at /home/jweil/gcc45/trunk/gcc/fortran/resolve.c:10990
#4  0x0000000000506280 in gfc_parse_file () at /home/jweil/gcc45/trunk/gcc/fortran/parse.c:3924
#5  0x000000000053af15 in gfc_be_parse_file (set_yydebug=0) at /home/jweil/gcc45/trunk/gcc/fortran/f95-lang.c:241
#6  0x000000000098408d in compile_file () at /home/jweil/gcc45/trunk/gcc/toplev.c:1026
#7  0x0000000000986232 in do_compile () at /home/jweil/gcc45/trunk/gcc/toplev.c:2346
#8  0x0000000000986302 in toplev_main (argc=2, argv=0x7fff2fc770a8) at /home/jweil/gcc45/trunk/gcc/toplev.c:2391
#9  0x00000000005ab99b in main (argc=2, argv=0x7fff2fc770a8) at /home/jweil/gcc45/trunk/gcc/main.c:35
Comment 6 janus 2009-07-14 13:50:10 UTC
The error goes away with the following patch:

Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c	(revision 149623)
+++ gcc/fortran/resolve.c	(working copy)
@@ -9845,20 +9845,6 @@ resolve_symbol (gfc_symbol *sym)
   if (sym->formal_ns && sym->formal_ns != gfc_current_ns)
     gfc_resolve (sym->formal_ns);
 
-  /* Make sure the formal namespace is present.  */
-  if (sym->formal && !sym->formal_ns)
-    {
-      gfc_formal_arglist *formal = sym->formal;
-      while (formal && !formal->sym)
-	formal = formal->next;
-
-      if (formal)
-	{
-	  sym->formal_ns = formal->sym->ns;
-	  sym->formal_ns->refs++;
-	}
-    }
-
   /* Check threadprivate restrictions.  */
   if (sym->attr.threadprivate && !sym->attr.save && !sym->ns->save_all
       && (!sym->attr.in_common

However, I don't quite see the connection yet. Also, this will regress e.g. on proc_ptr_22.f90 (which is the reason why I added this hunk for PR40646).
Comment 7 janus 2009-07-14 16:53:59 UTC
Here is a much better patch:

Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c	(revision 149623)
+++ gcc/fortran/resolve.c	(working copy)
@@ -9842,7 +9842,8 @@ resolve_symbol (gfc_symbol *sym)
   formal_arg_flag = 0;
 
   /* Resolve formal namespaces.  */
-  if (sym->formal_ns && sym->formal_ns != gfc_current_ns)
+  if (sym->formal_ns && sym->formal_ns != gfc_current_ns
+      && !sym->attr.contained)
     gfc_resolve (sym->formal_ns);
 
   /* Make sure the formal namespace is present.  */

At least this works for iso_varying_string.f90 and the procptr test cases. Starting a full regtest now.
Comment 8 janus 2009-07-15 08:41:52 UTC
Subject: Bug 40743

Author: janus
Date: Wed Jul 15 08:41:29 2009
New Revision: 149662

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149662
Log:
2009-07-15  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/40743
	* resolve.c (resolve_symbol): Don't resolve the formal namespace of a
	contained procedure.


2009-07-15  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/40743
	* gfortran.dg/interface_assignment_4.f90: New.


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

Comment 9 janus 2009-07-15 08:47:14 UTC
Fixed with r149662. Closing.