GCC Bugzilla has been upgraded from version 4.4.9 to 5.0rc3. If you see any problem, please report it to bug 64968.
Bug 44212 - [OOP] ICE when defining a pointer component before defining the class and calling a TBP then
Summary: [OOP] ICE when defining a pointer component before defining the class and cal...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: janus
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2010-05-20 13:54 UTC by Hans-Werner Boschmann
Modified: 2010-05-22 19:31 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.6.0
Last reconfirmed: 2010-05-20 20:14:13


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hans-Werner Boschmann 2010-05-20 13:54:22 UTC
module ice_module

  type :: B_type
     class(A_type),pointer :: A_comp   ! A_type is not yet defined
  end type B_type

  type :: A_type
  contains
     procedure :: A_proc
  end type A_type

contains

  subroutine A_proc(this)
    class(A_type),target,intent(inout) :: this
  end subroutine A_proc

  subroutine ice_proc(this)
    class(A_type) :: this
    call this%A_proc()
  end subroutine ice_proc

end module ice_module

f951: interner Compiler-Fehler: in gfc_add_component_ref, bei fortran/class.c:77

Sorry, the error is in german, but you will understand it :)
Comment 1 janus 2010-05-20 19:15:09 UTC
Confirmed.

I think the code is valid. At least 'A_type' being defined after 'B_type' is not a problem, since the Fortran 2003 standard says:

C438 (R440) If the POINTER attribute is not specified for a component, the declaration-type-spec in the component-def-stmt shall be CLASS(*) or shall specify an intrinsic type or a previously defined derived type.

C439 (R440) If the POINTER attribute is specified for a component, the declaration-type-spec in the component-def-stmt shall be CLASS(*) or shall specify an intrinsic type or any accessible derived type including the type being defined.

Comment 2 janus 2010-05-20 20:14:13 UTC
To fix this, one basically has to defer the generation of the vtype symbol to resolution stage, which is what the following patch does:


Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c	(revision 159561)
+++ gcc/fortran/resolve.c	(working copy)
@@ -10589,6 +10589,22 @@ resolve_fl_derived (gfc_symbol *sym)
   int i;
 
   super_type = gfc_get_derived_super_type (sym);
+  
+  if (sym->attr.is_class && sym->ts.u.derived == NULL)
+    {
+      /* Fix up incomplete CLASS symbols.  */
+      gfc_component *data;
+      gfc_component *vptr;
+      gfc_symbol *vtab;
+      data = gfc_find_component (sym, "$data", true, true);
+      vptr = gfc_find_component (sym, "$vptr", true, true);
+      if (vptr->ts.u.derived == NULL)
+	{
+	  vtab = gfc_find_derived_vtab (data->ts.u.derived, false);
+	  gcc_assert (vtab);
+	  vptr->ts.u.derived = vtab->ts.u.derived;
+	}
+    }
 
   /* F2008, C432. */
   if (super_type && sym->attr.coarray_comp && !super_type->attr.coarray_comp)
Index: gcc/fortran/parse.c
===================================================================
--- gcc/fortran/parse.c	(revision 159561)
+++ gcc/fortran/parse.c	(working copy)
@@ -2110,22 +2110,6 @@ endType:
 	  || c->attr.access == ACCESS_PRIVATE
 	  || (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.private_comp))
 	sym->attr.private_comp = 1;
-
-     /* Fix up incomplete CLASS components.  */
-     if (c->ts.type == BT_CLASS)
-	{
-	  gfc_component *data;
-	  gfc_component *vptr;
-	  gfc_symbol *vtab;
-	  data = gfc_find_component (c->ts.u.derived, "$data", true, true);
-	  vptr = gfc_find_component (c->ts.u.derived, "$vptr", true, true);
-	  if (vptr->ts.u.derived == NULL)
-	    {
-	      vtab = gfc_find_derived_vtab (data->ts.u.derived, false);
-	      gcc_assert (vtab);
-	      vptr->ts.u.derived = vtab->ts.u.derived;
-	    }
-	}
     }
 
   if (!seen_component)


This patch fixes the test case, but has not been regtested yet.
Comment 3 Dominique d'Humieres 2010-05-21 06:21:59 UTC
The patch in comment #2 fixes the ICE, but is probably the cause of

FAIL: gfortran.dg/select_type_1.f03  -O  (internal compiler error)
FAIL: gfortran.dg/select_type_1.f03  -O   (test for errors, line 63)
FAIL: gfortran.dg/select_type_1.f03  -O   (test for errors, line 65)
FAIL: gfortran.dg/select_type_1.f03  -O  (test for excess errors)

The ICE is

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/select_type_1.f03:54.77:

class default  ! { dg-error "cannot be followed by a second DEFAULT CASE" }
                                                                           1  
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/select_type_1.f03:56.77:

class default  ! { dg-error "cannot be followed by a second DEFAULT CASE" }
                                                                           2  
Error: The DEFAULT CASE at (1) cannot be followed by a second DEFAULT CASE at (2)
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

and the missing errors are

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/select_type_1.f03:63.11:

  type is (t2)  ! { dg-error "overlaps with CASE label" }
           1
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/select_type_1.f03:65.11:

  type is (t2)  ! { dg-error "overlaps with CASE label" }
           2
Error: CASE label at (1) overlaps with CASE label at (2)

Otherwise I did not noticed other side effects.
Comment 4 janus 2010-05-22 19:01:26 UTC
Subject: Bug 44212

Author: janus
Date: Sat May 22 18:55:53 2010
New Revision: 159745

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159745
Log:
2010-05-22  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/44212
	* match.c (gfc_match_select_type): On error jump back out of the local
	namespace.
	* parse.c (parse_derived): Defer creation of vtab symbols to resolution
	stage, more precisely to ...
	* resolve.c (resolve_fl_derived): ... this place.


2010-05-22  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/44212
	* gfortran.dg/class_22.f03: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/class_22.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/match.c
    trunk/gcc/fortran/parse.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog

Comment 5 janus 2010-05-22 19:31:34 UTC
Fixed with r159745. Closing.